| 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 |
RazielFMX
l33t
Joined: 23 Apr 2005
Posts: 835
Location: NY, USA
|
 Posted: Wed Oct 15, 2014 2:10 pm Post subject: |
 |
|
| steveL wrote: |
| 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++. |
I did read the article, and yes, C++ is one of the many languages I use. I choose the language for the design at hand; languages do not drive my design decisions. Attitudes like the author's would not last long in real world programming, at least for any company looking to turn a profit.
I believe mv hit it on the head:
| mv wrote: | | 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. |
|
|
| Back to top |
|
 |
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Thu Oct 16, 2014 5:11 am Post subject: |
|
|
And yet he doesn't even mention C++ in the article. That's just SO not the point.
So hf with that sidetrack. lul |
|
| Back to top |
|
|
Yamakuzure
Advocate
Joined: 21 Jun 2006
Posts: 2284
Location: Adendorf, Germany
|
| Posted: Thu Oct 16, 2014 10:19 am Post subject: |
|
|
| steveL wrote: | And yet he doesn't even mention C++ in the article. That's just SO not the point.
So hf with that sidetrack. lul |
Erm, steve? | The article you linked wrote: | I point to C++ as one of the first instances of what would later become “Worse is Better” culture.
(...)
Unpacking this a bit, I detect an admission that, yes, C++ is filled with hacks and compromises that everyone finds distasteful (“an octopus made by nailing legs onto a dog”), but that’s just the way things are, and the adults have accepted this and moved on to the business of writing software. Put more bluntly: STFU and get to work. |
I have started using C++ in 1996, and I am yet to find the "hacks and compromises that everyone finds distasteful" ...  ... did he, by any chance, confuse C++ with Objective-C? because that one is a dog with additional legs nailed to it. In random locations.
And Lisp? Remember the time when you needed dedicated Lisp machines that did nothing but to run one Lisp program because Lisp was too much of a resource hog to do it in any other way?
However, the author just picked C++ as one example because, well, no idea why. The rest is moving around some philosophical stuff that never reaches anything. A rather dull read if you ask me...
(Although I do share a few of his rants against CSS.  )
But I guess the worst statement, that really made me shake my head was: "Either we write software that is ugly and full of hacks, or we are childish idealists who try to create software artifacts of beauty and elegance." - I have seen (and done) both. In C, C++, Java, Perl, Python and more...
Unfortunately he lumps a lot together like that without any real substance behind it... 
_________________
Important German:- "Aha" - German reaction to pretend that you are really interested while giving no f*ck.
- "Tja" - German reaction to the apocalypse, nuclear war, an alien invasion or no bread in the house.
|
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Thu Oct 16, 2014 4:42 pm Post subject: |
|
|
Fine: it's still not the point of the article.
All that's been on display in here is exactly the kind of lazy thinking that the substantive part of the article is about. "Let's focus on one tiny part, since it demurs from our viewpoint of the world, and no-one's allowed to do that. We start whinging, and we're the internet generation: you don't want us to whinge at you.."
Address the substantive argument, or all this is is tedious pedantry that completely misses the point.
I for one have had enough of that on IRC: it's sad to see the same lack of thought, reflection and insight on the forums. |
|
| Back to top |
|
|
berferd
Tux's lil' helper
Joined: 13 May 2004
Posts: 117
|
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Thu Oct 16, 2014 8:17 pm Post subject: |
|
|
| berferd wrote: | | You're not looking very hard |
Among a few valid points (standard library not powerful enough - however the library of which language is more powerful?) the first link essentially critizes that C++ should make it easy to replace static typechecking by partially dynamic typechecking. I would consider it a feature that this is hard, because it shouldn't be used. And other things like sacrificing compile time vs. run-time are also a big feature of C++. That compilers take long and could do better with a better object format and some debuggers are bad: Obviously the author had no more arguments or otherwise would not need to refer to the implementation instead of the specficiation of the language.
The second link concerning D is just a fine proof of Stroustrups assertion about only two kind of languages:
C++ has some mild disadvantages, especially if being used in a wrong way. However, the many practical disadvantages (no widespread compiler, you cannot so easily use existing C code with no or only minor changes, people knownig C have to relearn, no standard library available on all systems) send D to the category of languages which are not used, even if in some ideal world they mgiht be better.
I don't know what you want to prove with the other links, especially the last one: That somebody is not using typedef's or auto and thus can produce ugly looking code is nothing new. It wouldn't look better in D if you do it this way. |
|
| Back to top |
|
|
berferd
Tux's lil' helper
Joined: 13 May 2004
Posts: 117
|
| Posted: Thu Oct 16, 2014 8:28 pm Post subject: |
|
|
| mv wrote: | | Obviously the author had no more arguments or otherwise would not need to refer to the implementation instead of the specficiation of the language. |
Haha! That lengthy section is just the summary of the worst issues with C++. The full FQA is much, much longer.
| mv wrote: | The second link concerning D is just a fine proof of Stroustrups assertion about only two kind of languages:
C++ has some mild disadvantages, especially if being used in a wrong way. However, the many practical disadvantages (no widespread compiler, you cannot so easily use existing C code with no or only minor changes, people knownig C have to relearn, no standard library available on all systems) send D to the category of languages which are not used, even if in some ideal world they mgiht be better. |
Stroustrup likes C++. I'm shocked. Shocked, I tell you!
BTW, you missed the point. I don't care about D. The point is that Walter Bright, who writes a professional C++ compiler, was driven to rage-invent a new language by all the misfeatures he had to deal with.
| mv wrote: | | I don't know what you want to prove with the other links, especially the last one: That somebody is not using typedef's or auto and thus can produce ugly looking code is nothing new. It wouldn't look better in D if you do it this way. |
False. All that gobbledygook is just defining a parser. I can and have defined parsers much more sanely and easily. Even YACC and Bison are better. |
|
| Back to top |
|
|
Navar
Guru
Joined: 20 Aug 2012
Posts: 353
|
| Posted: Fri Oct 17, 2014 3:58 am Post subject: |
|
|
Yes, let's jump into CFGs and lexical analysis... wait, what?
/me eyes title
Language 'discussions' can and should really veer off into their own thread, yes? |
|
| Back to top |
|
|
Roman_Gruber
Advocate
Joined: 03 Oct 2006
Posts: 3846
Location: Austro Bavaria
|
| Posted: Fri Oct 17, 2014 10:32 am Post subject: |
|
|
Serious to those trolls who asks us why we do not switch over to systemd. https://forums.gentoo.org/viewtopic-t-1002218-highlight-.html
Go and fix all the bugs in systemd. Fix the architecture and the design.
Fix all the bugs on this and on any gnu linux forum regarding systemd.
The more i see it by watching this forum the more i see it is the biggest source of bugs i ever saw in this gnu linux world. This forum is full of posts my machine does not does this or that because of systemd, like
One random out of thousands
https://forums.gentoo.org/viewtopic-t-1002216-highlight-.html
| Quote: | | I installed Gentoo for the first time. I selected the profile with gnome and systemd (and gdm). |
Well at least this user managed to write it on the first line what he uses but some users you have to ask directly which software they use.
EDIT: To those trolls / specialists / systemd-fanboys ....
Provide numbers and reasons why: Sane test method with explanation how it was tested. It has to be reproduceable, easy to understand and so on ...
IS it faster? I talk about 50-90 percent faster as any exisitng implementations
Is it clean? Easy to understand? easy to fix compared with any other existing implementation
Does it work well with existing solutions? |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Fri Oct 17, 2014 11:13 am Post subject: |
|
|
| tw04l124 wrote: | To those trolls / specialists / systemd-fanboys ....
Provide numbers and reasons why: Sane test method with explanation how it was tested. It has to be reproduceable, easy to understand and so on ...
IS it faster? I talk about 50-90 percent faster as any exisitng implementations
Is it clean? Easy to understand? easy to fix compared with any other existing implementation
Does it work well with existing solutions? |
++
And while you're there, show us how much time we save overall, over an average uptime of 6 months, with your go-faster boot.
If you're not used to thinking of profiling and performance optimisation in those terms, you're amateurs, and would you kindly go back to your swamp, and leave us alone now?
We've been through this kind of crap before, with paludroids, and we're not going to fold. |
|
| Back to top |
|
|
Roman_Gruber
Advocate
Joined: 03 Oct 2006
Posts: 3846
Location: Austro Bavaria
|
| Posted: Fri Oct 17, 2014 11:43 am Post subject: |
|
|
Just saw it today on another post mentioned
https://forums.gentoo.org/viewtopic-p-7576254.html#7576254
| Quote: |
Udev is part of systemd. For now it can be used separately without systemd but its current situation is somewhat blurry and causes constant confusion and problems.
To handle that, gentoo devs created a udev fork: eudev. Eudev is and will be completely independent from systemd.
So if you don't need/want to use systemd and don't want to be bother with crazy stuff on every udev update, you should switch to eudev: |
Just realized it is time to ditch udev. Since yesterday my box hangs on uevents beeing processed at booting. Could be udev or not but whatever I ditch udev now.
EDIT: After rebooting with eudev and uninstalled udev my box boots instantly again. The waiting for uvents beeing processed at booting with udev is gone. No more 20-60 seconds delay |
|
| Back to top |
|
|
Yamakuzure
Advocate
Joined: 21 Jun 2006
Posts: 2284
Location: Adendorf, Germany
|
| Posted: Fri Oct 17, 2014 12:01 pm Post subject: |
|
|
| berferd wrote: | | Yamakuzure wrote: | | I have started using C++ in 1996, and I am yet to find the "hacks and compromises that everyone finds distasteful" ... ... |
You're not looking very hard:
http://yosefk.com/c++fqa/defective.html |
I started with this one but left off after the first few topics. They are not describing defects, but just the opinion of the author.:
- No compile time encapsulation
Yes. This is a problem for software designers and not the language itself. That's why you ship pure interfaces that do *not* contain anything that can be subject to change. There are quite some established design patterns for that.
Honestly that is a matter of course whenever you ship interfaces to extern parties. Unless you are a member of the systemd developer crowd, of course.
- Outstandingly complicated grammar
No. This block is just not true. Because the "undecidable" grammar of C++ is a huge feature that makes it incredibly powerful.
And the "three things" he lists are nothing I can concur with from 18 years of experience. With some huge projects in between. A lot of cross compiling. And so on, and so on.
First, it compiles slowly, so what? Not an argument.
Second, warnings and error messages are incomprehensible? No. Quite the opposite. At least with GNU gcc and Microsoft Visual C++.
Third, IDEs get confused a lot? Well. From when is this article? 1998? Which IDE does he speak of? Borland C++ 5?
- No way to locate definitions
Again, a feature, that allows great flexibility, and certainly not a defect. The worst in this block is the statement, that you need to "compile" each header each time. Well. If your headers are full of inline code, than there is some truth in this. But that is not what headers are for, so that's entirely your fault.
And well, ever heard of pch?
Don't come with templates, please. They are special and only instantiated (and thus compiled) when they are actually needed and used.
- No run time encapsulation
Thank god! How good for anyone who uses C/C++ for system near programming!
Again: No defect, but a feature and a huge advantage for low level programming.
And by the way: Do they know -fstack-protector? Or -fsanitize=address?
I could go on, but honestly, he only presents remarkable features and tries to show off how broken C++ is.
The best example is the "Very complicated type system" paragraph, that just shows how little he understands of C++, and what makes it so incredibly powerful.
| berferd wrote: | | http://digitalmars.com/d/1.0/overview.html |
Yes. D is awesome. Why isn't it used in a wider scale?
Well, that's because of two problems it has:
First, it is very very young. So that one fixes itself over time. Automatically.
Second, D simply looks like (on the shallow surface) like it is nothing but a try to provide a "C++ without C". That is too little.
C-Compatibility is a huge advantage of C++. Actually, you can compile *any* good C source code with g++.
| berferd wrote: | | http://synesis.com.au/publishing/imperfect/cpp/ |
Mostly obsolete with C++11 and eventually C++14.
Sorry. But that is a bad example.
If you have any expertise in C++, you'll know, that that code would look a lot cleaner, smaller (but more obfuscated) with the right amount of using statements and typedefs. That's programmers choice. Do I want short lines, or do I want to present exactly what is going on? The compiler doesn't care...
So what?
And then they use boost. If you want to use boost, you just have to face such "namings".
And finally this is *not* modern C++, if it were, they'd use "uint32_t" instead of "uint32". 
_________________
Important German:- "Aha" - German reaction to pretend that you are really interested while giving no f*ck.
- "Tja" - German reaction to the apocalypse, nuclear war, an alien invasion or no bread in the house.
|
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Fri Oct 17, 2014 2:24 pm Post subject: |
|
|
| Yamakuzure wrote: | | No. This block is just not true. Because the "undecidable" grammar of C++ is a huge feature that makes it incredibly powerful. |
This is just crap. Sorry.
C++ has an ad-hoc grammar because of its kitchen-sink approach, especially in the early days, and because Stroustrup didn't really get yacc. Don't rest your argument on his amateur-hour idiocy.
On the wider point there's a great article that elucidates where "worse-is-better lol" has got us.
And this is why we're in this mess. |
|
| Back to top |
|
|
creaker
l33t
Joined: 14 Jul 2012
Posts: 651
|
| Posted: Fri Oct 17, 2014 3:01 pm Post subject: |
|
|
| imo, C++ isn't a programming language. It's a constructing language. You just pile superstructures one above other (templates, typedefs, classes, subclassing etc). It's completely abstracts you from the code itself. |
|
| Back to top |
|
|
schorsch_76
Guru
Joined: 19 Jun 2012
Posts: 450
|
| Posted: Fri Oct 17, 2014 4:34 pm Post subject: |
|
|
It seems that there are happening signs and wonders in our world!
https://lists.debian.org/debian-vote/2014/10/msg00001.html
Debian is holding a General Resolution about the switch to systemd. Two weeks before the feature freeze for the next release! |
|
| Back to top |
|
|
avx
Advocate
Joined: 21 Jun 2004
Posts: 2152
|
| Posted: Fri Oct 17, 2014 5:02 pm Post subject: |
|
|
Well, it's not really about the switch itself, it's more about if they would accept packages with hard dependencies on systemd and friends. In an ideal world, that maybe make them reconsider going systemd at all, but given the influence systemd-people seem to have in Debian, I currently highly doubt that they won't make it the default, sadly.
_________________
++++++++++[>+++++++>++++++++++>+++>+<<<<-]>++.>+.+++++++..+++.>++.<<+++++++++++++++.>.+++.------.--------.>+.>. |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6098
Location: Dallas area
|
| Posted: Fri Oct 17, 2014 6:00 pm Post subject: |
|
|
Debian is already dead, the head just hasn't informed the body so it's flopping around like a chicken with its head cut off.
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Fri Oct 17, 2014 8:10 pm Post subject: |
|
|
| Anon-E-moose wrote: | | Debian is already dead, the head just hasn't informed the body so it's flopping around like a chicken with its head cut off. |
I found that a laughable idea at first, but having read that thread, I'm forced to concur.
| Marco d'Itri wrote: | | even then, if this alleged pressure has been strong enough to make every non-kooky distribution adopt systemd then it should be obvious that resisting it would be futile for us as well. |
Such spine, it's amazing isn't it? If only we could be half as resolute.. /s.
Essentially he's saying "we should just capitulate to political pressure".
Daniel Kahn Gillmor gets sidetracked into his runit-based tools, apparently ignoring the exception for tools designed to work closely with a particular init-system. He later uses that as justification for supporting a much weaker GR, which has me staggered by this beauty:
| Lucas Nussbaum wrote: | | All software that currently supports being run under sysvinit should continue to support sysvinit unless there is no technically feasible way to do so. |
I just can't get my head round this idea of a daemon "supporting" an init-manager (or even more laughably, a particular init-process). It sounds totally wrong-headed to me; it reads like nonsense, and just makes me doubt the basic competence of anyone even presenting such a notion.
I can see where he's coming from in terms of wanting everyone "just to get along" so "let's just write up what people are saying", but this is the "leader" of the project?
Here's how to support sysvrc (which is what they're actually talking about) or any other daemon-manager: act as if they don't exist. A good one shouldn't need anything more from you than the ability to accept cli-switches when you're run. The same ones you've always put in to your daemons, depending on what they do.
Don't add any code which relies on a daemon-manager as that would be insane. Do nothing, instead, and add less bloat to your software.
Just make sure you don't insist on double-forking; at least provide a switch to do less, so we can manage the process directly via the kernel.
By all means support operation under xinetd: it's useful, and means we can "socket-activate" you if we want. Again, it simply means an option to do less: the parent process will pass you the listening socket, or spawn-per-request for the very simple cases.
As for debilian, I agree they're heading for the exit unless they wake up to the corporate 5th-columnists in their midst. I find it hard to believe that those career "developers" from other distros really are that stupid, for all their sheeple conformity. They're very good at the politicking, I'll give them that. (And would never, ever want people like that on a distro I were involved with; not that we get much option.)
| Florian Lohoff wrote: | The arguments to replace the init system were dishonest (We need dependency booting because booting is slow) in the beginning, and the arguments got replaced with completely different feature argumentation now.
..
Now - after a comparatively short time we are already in the position that degradation of the OSes capabilities when not using systemd is acceptable to some/most/all? of our developers.
|
|
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6098
Location: Dallas area
|
| Posted: Fri Oct 17, 2014 8:21 pm Post subject: |
|
|
| steveL wrote: | | Anon-E-moose wrote: | | Debian is already dead, the head just hasn't informed the body so it's flopping around like a chicken with its head cut off. |
I found that a laughable idea at first, but having read that thread, I'm forced to concur. |
I came to that conclusion when the "technical committee" steered debian towards sysd.
It wasn't a general consensus, it was driven by politicking (sound familiar) and by people
that should not have been making that decision for all of debian. But I doubt that sysd
could have made it as the "preferred" init system unless they went the way they did.
And the rest is history....
It's also a lesson for even gentoo, much as many of us don't like the idea that choice
could be taken away, we have our share of things foisted upon us by "a technical committee".
I like having a distro, especially one that offers choices, but if push came to shove,
I could and would just roll my own. Yes it's more work, and it's certainly not for everyone.
But I could avoid things like technical committees steering the distro simply because they've drank some koolaid.
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
happosai
n00b
Joined: 17 Aug 2005
Posts: 43
|
| Posted: Fri Oct 17, 2014 10:15 pm Post subject: |
|
|
They've already reached the number of seconds necessary, so they are going to discuss about this proposal for two weeks now. |
|
| Back to top |
|
|
ct85711
Veteran
Joined: 27 Sep 2005
Posts: 1791
|
| Posted: Fri Oct 17, 2014 11:23 pm Post subject: |
|
|
| I didn't read the branch off on that mail chain, but I know they also made a proposal to shorten it down to only one week (don't know if that was agreed upon or not). |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Sat Oct 18, 2014 5:00 am Post subject: |
|
|
| steveL wrote: | | Just make sure you don't insist on double-forking; at least provide a switch to do less, so we can manage the process directly via the kernel. |
I completely agree. However, this has a problem: When forking, it is clear that your daemon is "ready" after returning. But how can you tell this reliably when you are not forking? Unfortunately, there is a "standard" function missing where the daemon can tell back that he is "ready" now. Without such a function you always have a possible race...
| Quote: | | By all means support operation under xinetd: it's useful, and means we can "socket-activate" you if we want |
A built-in dependency on xinetd is also sort of a dependency on an init-system.
Or is it possible to do this without depending on xinetd? How? More precisely, I currently have perl code which looks like this:
| Code: | $socket = new IO::Socket::INET(
LocalAddr => ...,
LocalPort => ...,
Type => IO::Socket::SOCK_STREAM(),
Listen => IO::Socket::SOMAXCONN(),
Reuse => 1); |
Is there an easy compatbile way to rewrite this so that it allows socket activation with xinetd/systemd/....? |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Sat Oct 18, 2014 10:58 am Post subject: |
|
|
These are just my thoughts in response to what mv has written; by all means point out flaws in the reasoning, or gaps in my knowledge (so long as you have pragmatic insight into what's missing;) I'm not making any claims to expertise here, so please keep the sniping to a minimum, as it's a turn-off to collaborative discussion.
| mv wrote: | | steveL wrote: | | Just make sure you don't insist on double-forking; at least provide a switch to do less, so we can manage the process directly via the kernel. |
When forking, it is clear that your daemon is "ready" after returning. But how can you tell this reliably when you are not forking? Unfortunately, there is a "standard" function missing where the daemon can tell back that he is "ready" now. Without such a function you always have a possible race... |
Not really; they're the equivalent condition afaic. Double-forking doesn't tell you anything is ready, and indeed the daemon could still crash even though you've happily double-forked and returned "successfully". It happens quite a lot with proprietary crap, from what I hear.
Possible races in communication between parent and child are a slightly more generic matter, ime, which is why Stevens shows about 5 different variants on {TELL,WAIT}_{PARENT,CHILD}; it's old-hat iow (that would be the "standard" functionality you're talking about). When it comes to knowing a service is ready and functional, though there really isn't any shortcut round a correct monit() imo.
In passing I'd point out that we are still forking-- we're just not double-forking, which is done principally to start a new session, so that the daemon is in its own pgrp, and that is done because we want to avoid terminal signals. Which aren't an issue under a daemon-manager (it can take care of that once should it really need to, and no other daemon needs to worry about it.) There is still value in being in our own session for cgroups; again it's simpler for the manager to handle that.
Though I see what you're saying; the question is how can an init-manager know it's ok to go on and activate the next service. In a generic layer all you can really know is that the easy, generic steps have taken place. When double-forking that just means we've done the traditional daemon() setup and written a pidfile before the intermediate exited. It doesn't mean that we know our subsequent httpd is operating correctly, for example. Only that it started; and usually a daemon will crash much later, if it's going to crash.
The latter is why I'd like a monit() function in runscripts; for the httpd case it's pretty trivial (can we "GET /"?) but it's much better to keep that flexible, imo. Having it as part of a runscript means all the good things we've come to expect, like admin control and flexibility, with sane defaults suitable for the majority use-case.
Somehow it all works though doesn't it: a subsequent service may get started up before we're fully ready to serve, but we've got the socket open (first thing we do) so it's going to wait for us, and if we don't respond soon enough, the service won't function. Nine times out ten there really isn't an issue since the services critical for startup are accessed locally, and they're not competing for ports, nor is there any question of privilege (or there's an admin snafu.) Nor are most of them dodgy proprietary rubbish.
Simply knowing that the command has executed is usually enough. If not, it's pretty likely that admin intervention is going to be needed in any case. Again, proper monitoring is much more useful, afaic, though as ever this can be handled in the runscript too.
Complexity only needs to be added where needed, not across the board, and in the first instance we can it in shell, very efficiently. Similarly to how pre-conditions are also handled by openrc's "ssd" which is actually rc, we can optimise later, when needed.
I concede that a specific daemon can do more in the setup phase, so that it checks it can make a protocol request to its child, for example. I don't know many that do personally, but then I'm not a network coder. You are supposed to account for multiple startup in your protocol though, to truly avoid races around mutual exclusion. eg: if the AF_UNIX socket is already in place at its well-known path, so you can't create it with O_EXCL, then you have to be able to distinguish between a crash and another instance already running; and the only reliable way to do that is to have an "are you running?" request as part of the protocol. Simpler here than with scripts, since there is a socket, or some sort of service, to access by definition.
I'd just prefer it if we were adding a monitoring process in here ourselves, not a forked process that exits pretty much straightaway, so that we can use generic code in the same way we do for inetd (which handles the daemon setup for us, including the usual socket setup) as well as link in to our specific init-manager. So on the one side we have the "modern" or more correctly "traditional, non-hackish" approach of a daemon which runs in the foreground so we can know as soon as it exits, and that's nothing new.
On the other we're simply saying that whichever init-manager is handling that, can link into itself however it wants, but should not require any more from the daemon than any other portably written init-manager doing exactly the same thing. In fact that init-manager can and often will be a simple shell-script, eg when starting up an initramfs.
In our case, we'd like to monitor, and we're not afraid of leaving a process-per-service around to do exactly that, since processes have always been cheap on Unix.
I agree we need more added at openrc side though: if we're talking about not double-forking and using the standard mechanism (signal handler waiting til ECHILD) then that requires a process waiting for those events. My point is if you have that, then you know the daemon has exited, and how (eg if it crashes) and can adjust your dependency graph in response.
For the startup case, I could envisage simply delaying startup of a subsequent dependent til the monit() returns successfully, if there is one, and not worrying otherwise, unless we're specifically told to delay (eg to make sure the process doesn't crash within a second.)
I don't think we should get too caught up on the error case though, unless it's dodgy software. But we should definitely account for dodgy software, since admins in the real-world end up having to use it: and they normally know it's dodgy when they do so (or they'll find out soon enough;) They often complain about having to run some proprietary PoS for work, ime, that they have no choice but to run, even though they don't really want it anywhere near their machines.
It's not unreasonable simply to package that know-how in an openrc runscript, where needed, and provide the namespace and cgroup options required to constrain it.
| Quote: | A built-in dependency on xinetd is also sort of a dependency on an init-system.
Or is it possible to do this without depending on xinetd? |
Sure; inetd simply passes the socket on to you (inherited), duped across 0,1 and 2.
If you want the listening/main socket, then your daemon should be configured with the "wait" flag, in which case inetd will ignore the fd until you exit.
With "nowait" you'll be forked-per-connection, and given the accepted fd, as per a traditional (single-process) concurrent server; and inetd will continue to monitor the listening socket for new connections. (You don't want to use that with UDP afaik, though it is acceptable to inetd. It won't listen or accept on a UDP socket ofc.)
So I wouldn't call that a "dependency", in the systemdiot sense. It's an accepted convention going back over 30 years, similar to CGI, and doesn't require you to link in anyone's code.
It could only conceivably be called a dependency if someone were obfuscating the truth, and would be equivalent to them arguing that CGI forces you to use a particular language or library.
As ever you can use whatever cli-switches your users need. "Foregrounding" (ie: not backgrounding) should be the default, imo and always should have been; personally I'd use -x to mean "run automated/under inetd/socket already open" implying any -f option someone might add. For my tastes, I'd prefer an option to be used to run in the background, implicit when given a switch to use a pidfile.
Thanks for the interesting discussion. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Sat Oct 18, 2014 12:53 pm Post subject: |
|
|
SteveL, thanks a lot for your response, especially for the explanation how xinetd is supposed to work: I always thought that it is necessary that inetd-"daemons" must be linked against libinetd.so. So for my particular toy project, I just have to find out how to turn fd1 into a perl IO::Socket::INET object... (BTW: If some reader here knows how to do this, I would be grateful for a hint).
Concerning the race, you are right, of course, that a succesful return after a (single or double) fork does not necesarily mean that the daemon is ready to serve, and maybe some daemons fail with this. However, I would have expected that it is some sort of "standard" behaviour.
One final remark concerning "staying in the foreground" as default behaviour: I was recently surprised to learn that sshd (which is probably one of the most frequently used daemons, and since it is BSD, I would have expected that it tries to follow standards as close as possible) does not even have a "foreground"-switch: It only has a "debugging" switch which, however, cannot be used for "normal" working. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Sat Oct 18, 2014 1:53 pm Post subject: |
|
|
Since the language discussion is getting us completely OT, I did not plan to continue it here. Nevertheless, I think the following still should be clarified:
| berferd wrote: | | mv wrote: | The second link concerning D is just a fine proof of Stroustrups assertion about only two kind of languages:
C++ has some mild disadvantages, especially if being used in a wrong way. However, the many practical disadvantages (no widespread compiler, you cannot so easily use existing C code with no or only minor changes, people knownig C have to relearn, no standard library available on all systems) send D to the category of languages which are not used, even if in some ideal world they mgiht be better. |
Stroustrup likes C++. I'm shocked. Shocked, I tell you! |
This reply makes no sense. In the article we were discussing about, Stroustrup was cited with the quote "there are only two kinds of languages: the ones people complain about and the ones nobody uses". I was referring to this quote, of course.
| Quote: | | mv wrote: | | I don't know what you want to prove with the other links, especially the last one: That somebody is not using typedef's or auto and thus can produce ugly looking code is nothing new. It wouldn't look better in D if you do it this way. |
False. All that gobbledygook is just defining a parser. I can and have defined parsers much more sanely and easily. |
The word "false" makes logically no sense: "Somebody has written lengthy/bad/unreadable code in language A" and "One can write short/good/readable code in language B" are logically independent sentences, and are usually true whatever you insert for A or B. The reply makes even less sense after my above explanation how one might trivially get a much shorter code in the example. |
|
| 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
