Re: [gentoo-dev] [openrc] [systemd] make `service` common for both OpenRC and SystemD (like Debian/Ubuntu/whatever did)
On Sat, Sep 16, 2017 at 3:56 PM, Vadim A. Misbakh-Soloviov wrote: > > I'd like to suggest to remove `service` widget from openrc and make it the > part of (which package? baselayout?)? IMO this really should go in its own package. By all means have openrc and/or systemd pull it in by default, but this gives everybody a bit more control. This was the approach with functions.sh as well. > > P.S. actually, it also would be nice to add "generators" thing to it too, to > make it possible to manage services that have no systemd's units under SystemD > and services that have only units under OpenRC (well, that one looks much > harder than first variant, but, again, looks like deb/ubuntu guys did that > work already and we can try to use their work as cheatsheet) > We don't really have the same situation that they do. IMO this is best done by having some kind of wrapper that needs to be manually invoked. I think most people would want to know the first time they go to start a service that wasn't really tested under their particular configuration. The service might not work the way they expect, so they'd want to pay closer attention to it, for a start. Wrapping systemd units into openrc scripts should be relatively easy, because they're descriptive. You just need a parser of some kind. The only issue I see is any code that has to run in global context - I'm not sure how well openrc behaves when dependency parsing starts running code. Going in the other direction will be harder, but probably is possible. Honestly, though, it isn't like it is that hard to write a unit or script, so I think most people are going to prefer to hand-write them. One of the really nice things about Gentoo is that whether you use openrc or systemd you get a completely native experience without a ton of duct-tape adapting one system into a completely different one, full of caveats and stuff that doesn't behave like you'd expect. IMO the only other distro that delivers a similar experience with systemd is Arch, and they don't support openrc really. But, nobody is going to complain if you create a tool that creates init.d scripts or units automatically for you. People can use it as they wish, and it might or might not make a good starting point for a new script/unit. -- Rich
[gentoo-dev] [openrc] [systemd] make `service` common for both OpenRC and SystemD (like Debian/Ubuntu/whatever did)
Hi there!
Every time I switch from mastering service on my work (Ubuntu-powered) to my
own server farm (Gentoo powered) I'm going a bit frustrated: Ubuntu (with all
my hate to many other things in it) has nice user-friendly way of managing
services: you can freely call any of `service action` irrelevant
to which init-system is currently in use. Will it be systemd, or (whatever
there is alternative there). `service` wrapper will detect it anyway and will
do the proper things (forward it to either systemd or another service
manager).
I'd like to suggest to remove `service` widget from openrc and make it the
part of (which package? baselayout?)? Here is a pseudocode of how I see it:
```
servicename=${1}
action=${2}
if in_systemd; then
systemctl "${action}" "${servicename}"
else
rc-service "${servicename}" "${action}"
fi
```
Well, actually, there may be some more logic (for example, instance units
(`unit@instance` in `systemd` vs `unit.instance` in openrc), "enable" action
(forward it to `rc-update add` for `openrc`, probably) and maybe some more.
But anyway, the conception is something like that.
What do you think about that?
P.S. actually, it also would be nice to add "generators" thing to it too, to
make it possible to manage services that have no systemd's units under SystemD
and services that have only units under OpenRC (well, that one looks much
harder than first variant, but, again, looks like deb/ubuntu guys did that
work already and we can try to use their work as cheatsheet)
Re: [gentoo-dev] [RFC] Reinstating old-school GLEPs masterplan
W dniu sob, 16.09.2017 o godzinie 02∶51 -0500, użytkownik R0b0t1 napisał: > Hello, > > On Tue, Sep 12, 2017 at 9:04 AM, Michał Górny wrote: > > W dniu pon, 11.09.2017 o godzinie 21∶59 -0500, użytkownik R0b0t1 > > napisał: > > > Hello friends, > > > > > > On Mon, Sep 11, 2017 at 3:56 PM, Michał Górny wrote: > > > > W dniu pon, 11.09.2017 o godzinie 13∶29 -0400, użytkownik Michael > > > > Orlitzky napisał: > > > > > On 09/11/2017 01:08 PM, Michał Górny wrote: > > > > > > Hi, > > > > > > > > > > > > TL;DR: I'd like to reinstate the old-school GLEPs in .rst files > > > > > > rather > > > > > > than Wiki, put in a nice git repo. > > > > > > > > > > > > > > > > I generally agree with you that wiki markup is terrible and that a > > > > > text > > > > > editor and a git repo is The Right Way to do things (with Jekyll or > > > > > whatever to push it to the web). But in my experience, crappy and easy > > > > > is a better way to get people to contribute. When I've taken wiki > > > > > documents and moved them into git repos, more often than not I become > > > > > the sole contributor, and otherwise-technical people just start > > > > > emailing > > > > > me their contributions (which decrease greatly in frequency). > > > > > > > > [...] > > > > > > > > Then, you can just take www.gentoo.org and run it locally. It takes > > > > a little more effort but jekyll is really trivial to set up and run > > > > locally. Then you see it exactly how it's gonna look on g.o. > > > > > > > > I'm going to reply to the Gollum topic here since it's the first mail > > according to date. > > > > There is a thread in gentoo-dev where I proposed the Handbook be > maintained with Gollum. I apologize if it was not visible, but I was > trying to not make a nuisance of myself. > > > > I previously suggested Gollum and think I should suggest it again. > > > Gollum provides features relevant to a Wiki setting including web > > > editing. > > > > Firstly, a generic request to everyone. If you want to suggest that we > > are supposed to use your-favorite-tool instead of the one we have > > deployed for a few years now, then please include: > > > > I believe I addressed all of these. Please make suggestions on my > writing so I can make it more readable if you have the time. > > If I suggest a project I think it reasonable to expect you to refer to > that project's README. Here is a link: > https://github.com/gollum/gollum/blob/master/README.md. > > > 1. A short summary including: > > > > 1a. How it fits into the desired workflow. Topics such as access control > > and caching are of particular interest to me. > > > > It manages a Wiki using a Git repository. Access control is managed > through the Git repository and has Git's limitations. When using > Gollum it seems like access control is best done by creating > repositories. The web editor seems to lack authentication. That's what I suspected. So you're talking about deploying a wiki without the basic feature of a wiki. IOW, once again deploying a tool more complex than necessary, and working it around to make it work for our purpose. > Gollum may have issues with caching[1]. Gollum is deployed by GitHub, > but most GitHub project Wikis may be small. That's not an answer. Generating all GLEPs takes around 60 seconds right now. With jekyll, that's done once. If gollum regenerates them frequently, it's not a feasible solution. > > 1b. What possible future use it could have. > > > > It could maintain all public facing documents. > > > 1c. How much effort will the future maintenance take. > > > > I do not see how it would take more maintenance time than Jekyll. It > may take less as it offers Wiki specific features. There's a major difference between maintaining one tool we know, and two tools (because obviously we won't dump Jekyll instantly), the second one we don't know anything about. > > 2. A publicly available working instance that resembles the workflow > > we're aiming for, or an easy way of setting one up. Easy = ~5 simple > > shell commands, not 'set a webserver up'. > > > > The README offers concise instructions for setting up a demonstration > instance and scaling up. Should that be hard to read, a video is > available (https://www.youtube.com/watch?v=EauxgxsLDC4). That's not what I'm asking for. If it's that easy, then set it up. What I want is a 'one click' solution that can get me running it without major changes to my system, without effort on my end and in, say, less than 5 minutes. -- Best regards, Michał Górny
Re: [gentoo-dev] [RFC] Reinstating old-school GLEPs masterplan
Hello, On Tue, Sep 12, 2017 at 9:04 AM, Michał Górny wrote: > W dniu pon, 11.09.2017 o godzinie 21∶59 -0500, użytkownik R0b0t1 > napisał: >> Hello friends, >> >> On Mon, Sep 11, 2017 at 3:56 PM, Michał Górny wrote: >> > W dniu pon, 11.09.2017 o godzinie 13∶29 -0400, użytkownik Michael >> > Orlitzky napisał: >> > > On 09/11/2017 01:08 PM, Michał Górny wrote: >> > > > Hi, >> > > > >> > > > TL;DR: I'd like to reinstate the old-school GLEPs in .rst files rather >> > > > than Wiki, put in a nice git repo. >> > > > >> > > >> > > I generally agree with you that wiki markup is terrible and that a text >> > > editor and a git repo is The Right Way to do things (with Jekyll or >> > > whatever to push it to the web). But in my experience, crappy and easy >> > > is a better way to get people to contribute. When I've taken wiki >> > > documents and moved them into git repos, more often than not I become >> > > the sole contributor, and otherwise-technical people just start emailing >> > > me their contributions (which decrease greatly in frequency). >> > >> > [...] >> > >> > Then, you can just take www.gentoo.org and run it locally. It takes >> > a little more effort but jekyll is really trivial to set up and run >> > locally. Then you see it exactly how it's gonna look on g.o. >> > > > I'm going to reply to the Gollum topic here since it's the first mail > according to date. > There is a thread in gentoo-dev where I proposed the Handbook be maintained with Gollum. I apologize if it was not visible, but I was trying to not make a nuisance of myself. >> I previously suggested Gollum and think I should suggest it again. >> Gollum provides features relevant to a Wiki setting including web >> editing. > > Firstly, a generic request to everyone. If you want to suggest that we > are supposed to use your-favorite-tool instead of the one we have > deployed for a few years now, then please include: > I believe I addressed all of these. Please make suggestions on my writing so I can make it more readable if you have the time. If I suggest a project I think it reasonable to expect you to refer to that project's README. Here is a link: https://github.com/gollum/gollum/blob/master/README.md. > 1. A short summary including: > > 1a. How it fits into the desired workflow. Topics such as access control > and caching are of particular interest to me. > It manages a Wiki using a Git repository. Access control is managed through the Git repository and has Git's limitations. When using Gollum it seems like access control is best done by creating repositories. The web editor seems to lack authentication. Gollum may have issues with caching[1]. Gollum is deployed by GitHub, but most GitHub project Wikis may be small. > 1b. What possible future use it could have. > It could maintain all public facing documents. > 1c. How much effort will the future maintenance take. > I do not see how it would take more maintenance time than Jekyll. It may take less as it offers Wiki specific features. > 2. A publicly available working instance that resembles the workflow > we're aiming for, or an easy way of setting one up. Easy = ~5 simple > shell commands, not 'set a webserver up'. > The README offers concise instructions for setting up a demonstration instance and scaling up. Should that be hard to read, a video is available (https://www.youtube.com/watch?v=EauxgxsLDC4). > 3. A statement from an Infra member that is willing to set the instance > up and maintain it. > It seems like it is your burden to interpret the suggestion and refer it to the people who would be maintaining it. If you don't want to then that is fine. > Because otherwise we're only going to lose time on theoretical debates > over software without even knowing if it will work at all, do what it's > supposed to do, and most importantly, if someone will actually set > a production instance up and maintain it afterwards. > It is not possible for me to know everything you would like addressed in advance. Most of the problems Gentoo faces are unique enough that I do not think it is reasonable to expect a useful solution to exist. There will always be problems. > Infra already maintains enough diverse platforms/services/frameworks > that serve only a single tool selected by one person who used to like > it, and not maintained anymore. SMW belongs to that group. > >> It would not require pages be rewritten and can render >> MediaWiki that is maintained in a Git repository. > > Secondly, even if Gollum supported MW markup to the point of rendering > GLEPs (which it doesn't [1]), MW markup is not suitable for any > technical specifications or serious documentation for two reasons: > > a. MW markup is not proper WYWIWYG. Any more complex part of > the document is not readable as plaintext. Add to that the horrible > syntax requiring use mixed with inline HTML... > > b. MW markup is not standalone. Our GLEPs already started heavily > depending on random templates (which can
