Talk:OpenRC

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

Unknown title[edit]

137.250.125.128, wikipedia diff is not an athoritative reference. If you think that OpenRC upstream isn't friendly (in particular, because they lied about their competitors), please explain this in more extensive form, with references to their wiki. Setting moot point to neutral for now. 194.85.169.46 (talk) 09:40, 27 April 2012 (UTC)[reply]

Which is the lie exactly? If there is something incorrect in what I wrote or reported please either edit or point it out. By the way I'm not upstream. LucaUBarbato (talk)
Source page in Gentoo wiki (for now) almost entirely consists of such "incorrect" information, and all of these "incorrectancy" hits the same goal. It's looks very dirty, and compromising the overall project. Upstream developers must control own wiki. If you care about the project, please inform upstream of the situation, and help them to solve the problem. 194.85.169.43 (talk) 20:32, 27 April 2012 (UTC)[reply]
You are not stating something I can fix, you are basically handwaving "I do not like what you say", not explaining what nor how you'd like to fix. So, Anonymous, either you state what is not factual or wrong, so I can fix, or you might not continue with this game. I'd be anyway glad if you could please avoid the term "lie" and "dirty" 76.95.212.76 (talk) —Preceding undated comment added 04:53, 29 April 2012 (UTC).[reply]
First of all, I haven't edited the article or the talk page before. I'm also a bit biased and know some init systems better than others.
That being said, LucaUBarbato is certainly upstream "enough" as a Gentoo developer, even if he is not directly involved with OpenRC. Also, I do believe that the big changes introduced to the article are related to the OpenRC developers starting to push their init system as an alternative in Debian[1] and ArchLinux[2]. The changes LucaUBarbato made are clearly not intended to describe OpenRC, but to advertise it. Phrases such as "OpenRC bonus features" or unscientific measurements such as "friendly upstream" or "support for bare-metal bare-dependency servers" (whatever this means) prove this.
If it comes to lies: there are quite a lot of them in the changes introduced by LucaUBarbato, most of them in the features table[3]. For example,
  • he claimed that systemd had no separation of code and configuration
  • he claimed that systemd's automatic dependency calculation and service ordering was incomplete ("mostly-yes")
If you compare the feature comparison now and when LucaUBarbato introduced it, you'll find that most entries differ, and the wrong entries introduced by LucaUBarbato were always supporting OpenRC.
The size and complexity section is also not suitable due to being incomplete. E.g. systemd dependencies are listed, but OpenRC is missing the shell dependency (to my knowledge, OpenRC requires a shell; systemd does not). It is stated that a change in size from ~3LOC to ~15LOC can be explained by moving from shell to C, without supporting this statement. cryptsetup is mentioned as an optional dependency of systemd even though it is an optional dependency of every init system.
In any case, neither the feature comparison nor the size discussion belong into the OpenRC article (they could move to a comparison article, but I don't think that's a good idea). Instead, there should be a feature section that mentions real features of OpenRC including references. -- 77.4.168.110 (talk) 19:43, 29 April 2012 (UTC)[reply]

Do you folks have any idea where you are? Neither this discussion, nor the content of the article, is appropriate for Wikipedia. I mean really: "OpenRC is 100% compatible with Gentoo init scripts, which means you can probably find one for the daemons you want to start in the Gentoo Portage Tree." ?? Wikipedia is not a Gentoo User Guide. -- 96.248.226.133 (talk) 04:12, 4 June 2013 (UTC)[reply]

License Color Coding[edit]

It seems to me that the color-coding of the license section in the comparison table makes a VERY subjective value judgment.

The licenses used by each init system are factual. The coloring in general implies better/worse, and there is no such thing as a "better/worse" license unless there is some agreed-upon standard.

I'm sure there are many who would apply the colors in an opposite manner. I would suggest making the coloring neutral as a result.

The table itself isn't a bad thing, but it almost seems like it belongs in a more general article on sysvinit systems, and not OpenRC in particular. Rich0 (talk) 03:29, 13 July 2012 (UTC)[reply]

Overall, it feels like the article "reads like an advertisement" 92.105.161.57 (talk) 20:57, 18 July 2012 (UTC)[reply]
Given the name of the license line in the table (License is friendly for proprietary use), the color coding makes sense. - Apotheon (talk) 17:24, 13 February 2013 (UTC)[reply]
Rather than participate in discussion and help arrive at a generally acceptable solution, User:DonCuan decided to take unilateral action to make the table look like shit. I reverted his change but, in hopes of heading off a revert-war with him, I altered the text of the License line to hopefully give it a more neutral tone while maintaining the cohesive appearance of the table. No hard feelings if this gets reverted too; I'm just trying to foster some reasonable solution development here. - Apotheon (talk) 03:56, 14 February 2013 (UTC)[reply]

systemd's "proper modular architecture"[edit]

systemd is NOT properly modular: it is closely-coupled to lots of other things, and not at all cohesive: it does too much, running as PID 1 which is the worst thing, contortions around sockets and copying data to deal with the fact that it also wants to be xinetd etc.

Such claims are the result of ignorance of technical details, or willful wishful thinking.

First of all, let's look for a socket activation, which "must be" moved into the xinetd. xinetd was originally designed to run network services. It has't functionality which needed to control of normal system services (i.e. ability to start, stop, reload, check the status from the commandline, or satisfaction of dependencies at service startup/shutdown). Thereas launchd/systemd-style socket activation intended primarily for system services, such as syslog, CUPS, bluetoothd. Do you wish that your syslog service will be started by xinetd? However, xinetd still does not support launchd/systemd-style socket activation.

If xinetd will be used for socket activation of system services, this would require not only adding support for launchd/systemd-style socket activation, but copy the most of the functionality of init. If you like this idea, you can fork xinetd and do this, and when your project succeed, you will have the full right to accuse systemd about improper structure and duplicate functionality ;-)

The next, look for a systemd timers. At first glance, the function of these timers is similar to cron/at, but in fact they does not intersect. For example, typical cron task "run this program everyday at 8:00 PM", or typical at task "run this tomorrow at 9:00 AM", cannot be programmed with systemd timers. In the other hand, typical systemd timers "run this service in 5min after boot", "run foo.service in 1min after exiting of bar.service" etc, cannot be (easily) programmed with cron/at.

Finally, it should be noted that implementation bigger path of systemd functionality, such as timer-, path- and device-based activation, made in the separate program, developed by other project - in the Linux kernel. systemd only load configuration files, and make appropriate calls to the kernel. After that, the kernel itself watches the paths, waiting for timers and react to the devices. If you so want to quarrel about the improper structure - you can go directly to Torvalds ;-)

Also, if you're going to blame upstart - please take the trouble to cause arguments.

Sorry my bad English. WBR, 194.85.169.11 (talk) 11:47, 23 July 2012 (UTC)[reply]

Much worse then your awful English is your writing at length about "systemd" on a discussion page for the "OpenRC" article. -- 96.248.226.133 (talk) 04:12, 4 June 2013 (UTC)[reply]

Merge?[edit]

Why don't merge the Linux init articles in one article. A big part of the information is about the same things in all of them. Now the separate articles is like a (bad) advertisement for respective init system and it really hard to get any useful reliable information from any of them. One article with a good summary of the different systems, how they differ from each otters and similarities could give a better comprehension for the reader. — Preceding unsigned comment added by 95.209.52.215 (talk) 13:44, 9 February 2013 (UTC)[reply]

They aren't all just Linux init systems. For instance, OpenRC is apparently being used for ArchBSD. - Apotheon (talk) 17:25, 13 February 2013 (UTC)[reply]
Irrelevant quibble; they're POSIX init systems. There are better arguments against merging them. -- 96.248.226.133 (talk) 04:12, 4 June 2013 (UTC)[reply]

Alpine Linux uses OpenRC[edit]

Might want to add Alpine uses OpenRC by default on it's alpine-3.1.3 ISO files, likely due to it's low resource requirements. (And likely in the future, Alpine Linux will utilize Suckless's core, etc. (Suckless projects, and now "musl libc", tend to have very interesting projects!) — Preceding unsigned comment added by Rogerx (talk • contribs) 15:42, 30 March 2015 (UTC)[reply]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:OpenRC&oldid=1202062891"