Did it actually evict all the page cache or did you hit the overcommit limit to trigger the OOM killer?
I don't know; I only used Linux here because the Android build system doesn't seem very portable. Not too familar with the implementation details of Linux' OOM killer. Here's the log
The linker (gold) is responsible for the OOM-situation by having by far the largest amount of allocated memory, but it's the java compiler that actually triggers the OOM killer, causing gold to be killed. This somehow makes sense, but at the same time, meh. In my particular case, I'd have preferred the linking to succeed, at the cost of javac. But well, it's heuristic.
I have mixed feelings about the killing of processes; while I don't necessarily agree with the method, I can't argue with the results. Still, it'd be nice to try a SIGHUP and SIGTERM first.
Yeah. Actually in the logs i linked above, there's no indication of what signal was delivered; I think on the command line it gave something along the lines of ``terminated by signal 9''. I might have been mixing it up, with something else, too. Then again thinking about it, the "more polite" signals are probably futile in a OOM situation.
I'd be happier if this statement wasn't followed by yet another blob of gibberish demonstrating that you're still in your old MO.
It just delicious how you can link completely unrelated things trying to prove your point.
Unrelated?
That certainly would explain a lot of your inability to show real facts about how systemd architecture should be improved.
Huh, facts? It's so fundamentally flawed that the only way I see to "improve" systemd involves the rm(1) program. You see, the same thing you think about system V init.
Networking appliances are traditionally where BSD in fact is often used. I'm not denying that Linux has gained significant popularity, I even said that.
satellite boxes, modern TVs, cable boxes, satellite boxes, DVRs, streaming video sticks/boxes, etc.
So these all run Linux nowadays, okay. TIL.
Most of the time the printed manual that came with the frickin' TV has two or three pages devoted to a print out of the GPL
I'll just assume that you have in fact bought enough of that stuff to have statistical significance and checked all manuals for the fine print. The stuff must really be piling up at your place...
Yes, there's a lot of software shipped under more liberal licenses that make it too, such as the Apache license. But specifically BSD... it's comparatively rarely seen these days.
What I meant by 'lately' in this case would be somewhere in the ballpark of one decade. If you are an embedded developer/designer, then you'll probably be aware of the typical constraints with respect to memory size, both program storage and RAM. Now, ignoring that the vast majority of embedded systems isn't remotely equipped to run Linux or BSD in the first place, which sort of relativates both our claims, for the systems that in fact do, BSD kernels tend to be quite a bit smaller than their Linux equivalent with similar functionality, so the decision has a direct impact on cost. Additionally, using Linux the license requires to (gasp) release the sources, and before this getting better in the last decade, for most companies that was a total no-go.
BTW, an example of where embedded systems/appliances of significant size were/are often BSD based would be networking equipment; maybe this is because the BSDs seem to be widely known and have a reputation among networking people.
Anyway, as pointed out above, most embedded systems are so small that there's no way to run either a BSD or Linux, or any OS for that matter, on, rendering the whole discussion rather pointless. In fact I'd suppose you'd need at least 8M of RAM (maybe 16M for Linux) to get going; I've developed my share of embedded systems and even the thought of having 8 or 16 KB of RAM makes me go "hmm, big thing".
why would we want -S and -r? -a makes absolutely no sense in the use case.
but you superbly fail to notice that this is actually the -a option that do nothing in this case.
Everytime I think you couldn't possibly demonstrate even more stupidity, you prove me wrong. I hope your neglibible IQ isn't representative for systemd-proponents, although that certainly would explain a lot.
As early as 2003 I was getting software sold by Halliburton
Nice observer-biased anecdata.
Fast forward to now and "busybox" is in just about every little device with a CPU you can think of. It's GPL licenced software.
I specifically said that the situation has gotten better these days, no need to tear down a straw man just for this. Plus, busybox is by far not in "just about every little device with a CPU", wtf.
The difference is scope. mysql-tools depending on mysql makes sense, because their scope is handling of a mysql database (which could notably be handled through generic SQL clients as well as replaced for, say, postgres, but that's beside the point).
systemd's scope is more like 'the universe, the entire system and everything'.
Without attempting to judge whether or not what you describe it's a good idea, that doesn't sound exactly like 'one specific purpose' but 'a kitchen-sink of various vaguely related things'
You can easily try it yourself, as it is reproducible every time.
I wouldn't have been so curious if i hadn't happen to have encountered a similar situation, but without the mysterious swap-but-no-swap stuff happening. (See my response to sibling for details).
If what you say is true, then you're swapping. If linux does that automatically now, even when swap is disabled, I'm happier than ever to use a BSD...
swappiness won't help him if he doesn't have any swap. He probably does have swap but isn't aware of it.
For the record, I built CyanogenMod the other day on a Debian machine with actually no swap, and at some point when linking chromium, the linker would consume more RAM than i had available (roughly 2.5 gig). When it reached that point, the process received a SIGKILL by the OOM-killer (a questionable concept, but that's beside the point).
There was a link in my comment; please read it. It exactly addresses that question. Apart from that, personally, if i for some reason had to choose between a) seeing my code be useful in the real world, with no compensation; and b) seeing my code rot away in uselessness, i'd take a) thank you very much (for nothing).
Please tell me how did BSD win from OS X using it as a code base.
If you're under the impression that at some point the OS X (or predecessors) developers took a complete BSD and forked it, then you're mistaken. Parts of the userland originally came from BSD, but that's about it. Notably, it doesn't run a BSD kernel either.
Anyway, just to answer your question even though it's flawed: how about CUPS being very solid on the BSDs?
Too funny that the person you're agreeing with demonstrated poor knowledge of ls(1), one of the very most fundamental CLI programs in the post you're agreeing with. You're as dumb as that shill is, perhaps dumber.
So on Fedora, there are (at most (*)) 210 occurances of init script sourcing one particular system V helper script which, judging by the name, defines common shell functions used by multiple init scripts. What exactly is your point here? The content of/etc/init.d/functions should be replicated 210 times in each of the respective scripts rather than being sourced? With that idea of good design, it doesn't surprise me you're a systemd proponent.
Why do i have the feeling that your real intention was to make a casual reader believe that there were 210 "system-wide" scripts (whatever the fuck thats supposed to mean in this context, what is/not/ system wide at init time?) littered all over the place that the init scripts would depend on. Nice try.
And after failing that hard...
This shows how little you understand the arguments you're making
which leaves me thinking about pots and kettles.
(*) of course the actual command is a failure too, since that period is a wildcard and no boundary is given either. So even a comment somewhere in a script reading "# by the way, we would never source/etc/init.d/functions" would mistakenly be included in your already pointless measurement. For the record, a competent AC would have used
The argument is 'splitting hairs' because it's getting at the wrong point. The problem with systemd isn't that the init scripts (or unit files) depend on systemd......
And noone said that.
If you click "Parent" often enough you'll arrive at a +5 Insightful comment quoted below:
Systemd is a collection of small executables each with a precise goal, in line with the UNIX philosophy. Do a "ls -alSrh/lib/systemd/systemd-*/usr/bin/systemd-*" if you want to verify this fact.
I've spent enough time "arguing" with this troll, so I'll just mock him for "-alSrh" this time. Obviously memorized instead of arrived at by understanding ls(1); why would we want -S and -r? -a makes absolutely no sense in the use case.
Reminds me of a guy who will always use ``grep -nir'', no matter whether he actually wants line numbers, case insensitivity and/or recursion, simply because ``grep -nir'' was the first usage of grep he saw, and he decided to just memorize it because at some point it was useful, rather than finding out what he actually did and what more there is. jcdr with his ``ls -alSrh'' strikes me as being of the same kind. Loud and clueless.
The point is not so trivial because init scripts allegedly depending on init was brought up as an analogy to systemd-younameit depending on systemd, which was in turn used to point out that systemd is modular and therefore quite the UNIX way. It doesn't get much wronger.
Also, splitting hairs is surprisingly nontrivial;)
Slashdot Mirror
I had that happen to me, and my identity wasn't stolen. I still had it.
Yeah, I couldn't agree more. It's not identity theft, it's identity copyright infringement
Are you sure you understand why Duff's Device works? You can't do that with a "range" case, even if they would exist
You generally don't directly deal with the hardware in userspace; what language is used is entirely irrelevant.
How many languages have direct hardware access?
How the hell can a language have "direct hardware access?". What's that even supposed to mean?
A thousand times this.
Eh, swallowed some quote tags there, sorry.
Did it actually evict all the page cache or did you hit the overcommit limit to trigger the OOM killer?
I don't know; I only used Linux here because the Android build system doesn't seem very portable. Not too familar with the implementation details of Linux' OOM killer.
Here's the log
The linker (gold) is responsible for the OOM-situation by having by far the largest amount of allocated memory, but it's the java compiler that actually triggers the OOM killer, causing gold to be killed. This somehow makes sense, but at the same time, meh. In my particular case, I'd have preferred the linking to succeed, at the cost of javac. But well, it's heuristic.
I have mixed feelings about the killing of processes; while I don't necessarily agree with the method, I can't argue with the results. Still, it'd be nice to try a SIGHUP and SIGTERM first.
Yeah. Actually in the logs i linked above, there's no indication of what signal was delivered; I think on the command line it gave something along the lines of ``terminated by signal 9''. I might have been mixing it up, with something else, too.
Then again thinking about it, the "more polite" signals are probably futile in a OOM situation.
Ok, you have see it and I did not notice. Happy ?
I'd be happier if this statement wasn't followed by yet another blob of gibberish demonstrating that you're still in your old MO.
It just delicious how you can link completely unrelated things trying to prove your point.
Unrelated?
That certainly would explain a lot of your inability to show real facts about how systemd architecture should be improved.
Huh, facts?
It's so fundamentally flawed that the only way I see to "improve" systemd involves the rm(1) program. You see, the same thing you think about system V init.
most smartphones
Not embedded.
home routers
Networking appliances are traditionally where BSD in fact is often used. I'm not denying that Linux has gained significant popularity, I even said that.
satellite boxes, modern TVs, cable boxes, satellite boxes, DVRs, streaming video sticks/boxes, etc.
So these all run Linux nowadays, okay. TIL.
Most of the time the printed manual that came with the frickin' TV has two or three pages devoted to a print out of the GPL
I'll just assume that you have in fact bought enough of that stuff to have statistical significance and checked all manuals for the fine print. The stuff must really be piling up at your place...
Yes, there's a lot of software shipped under more liberal licenses that make it too, such as the Apache license. But specifically BSD... it's comparatively rarely seen these days.
Yeah.
What I meant by 'lately' in this case would be somewhere in the ballpark of one decade.
If you are an embedded developer/designer, then you'll probably be aware of the typical constraints with respect to memory size, both program storage and RAM. Now, ignoring that the vast majority of embedded systems isn't remotely equipped to run Linux or BSD in the first place, which sort of relativates both our claims, for the systems that in fact do, BSD kernels tend to be quite a bit smaller than their Linux equivalent with similar functionality, so the decision has a direct impact on cost.
Additionally, using Linux the license requires to (gasp) release the sources, and before this getting better in the last decade, for most companies that was a total no-go.
BTW, an example of where embedded systems/appliances of significant size were/are often BSD based would be networking equipment; maybe this is because the BSDs seem to be widely known and have a reputation among networking people.
Anyway, as pointed out above, most embedded systems are so small that there's no way to run either a BSD or Linux, or any OS for that matter, on, rendering the whole discussion rather pointless. In fact I'd suppose you'd need at least 8M of RAM (maybe 16M for Linux) to get going; I've developed my share of embedded systems and even the thought of having 8 or 16 KB of RAM makes me go "hmm, big thing".
why would we want -S and -r? -a makes absolutely no sense in the use case.
but you superbly fail to notice that this is actually the -a option that do nothing in this case.
Everytime I think you couldn't possibly demonstrate even more stupidity, you prove me wrong.
I hope your neglibible IQ isn't representative for systemd-proponents, although that certainly would explain a lot.
As early as 2003 I was getting software sold by Halliburton
Nice observer-biased anecdata.
Fast forward to now and "busybox" is in just about every little device with a CPU you can think of. It's GPL licenced software.
I specifically said that the situation has gotten better these days, no need to tear down a straw man just for this. Plus, busybox is by far not in "just about every little device with a CPU", wtf.
The difference is scope. mysql-tools depending on mysql makes sense, because their scope is handling of a mysql database (which could notably be handled through generic SQL clients as well as replaced for, say, postgres, but that's beside the point).
systemd's scope is more like 'the universe, the entire system and everything'.
Without attempting to judge whether or not what you describe it's a good idea, that doesn't sound exactly like 'one specific purpose' but 'a kitchen-sink of various vaguely related things'
Instead of reading only the first 6 words of the comment you're replying to, try reading at least the first 12 words.
You can easily try it yourself, as it is reproducible every time.
I wouldn't have been so curious if i hadn't happen to have encountered a similar situation, but without the mysterious swap-but-no-swap stuff happening. (See my response to sibling for details).
If what you say is true, then you're swapping. If linux does that automatically now, even when swap is disabled, I'm happier than ever to use a BSD...
swappiness won't help him if he doesn't have any swap. He probably does have swap but isn't aware of it.
For the record, I built CyanogenMod the other day on a Debian machine with actually no swap, and at some point when linking chromium, the linker would consume more RAM than i had available (roughly 2.5 gig). When it reached that point, the process received a SIGKILL by the OOM-killer (a questionable concept, but that's beside the point).
And why would that be an upside?
There was a link in my comment; please read it. It exactly addresses that question.
Apart from that, personally, if i for some reason had to choose between a) seeing my code be useful in the real world, with no compensation; and b) seeing my code rot away in uselessness, i'd take a) thank you very much (for nothing).
Please tell me how did BSD win from OS X using it as a code base.
If you're under the impression that at some point the OS X (or predecessors) developers took a complete BSD and forked it, then you're mistaken. Parts of the userland originally came from BSD, but that's about it. Notably, it doesn't run a BSD kernel either.
Anyway, just to answer your question even though it's flawed: how about CUPS being very solid on the BSDs?
Too funny that the person you're agreeing with demonstrated poor knowledge of ls(1), one of the very most fundamental CLI programs in the post you're agreeing with. You're as dumb as that shill is, perhaps dumber.
What's logind's specific purpose?
So on Fedora, there are (at most (*)) 210 occurances of init script sourcing one particular system V helper script which, judging by the name, defines common shell functions used by multiple init scripts. What exactly is your point here? The content of /etc/init.d/functions should be replicated 210 times in each of the respective scripts rather than being sourced? With that idea of good design, it doesn't surprise me you're a systemd proponent.
Why do i have the feeling that your real intention was to make a casual reader believe that there were 210 "system-wide" scripts (whatever the fuck thats supposed to mean in this context, what is /not/ system wide at init time?) littered all over the place that the init scripts would depend on. Nice try.
And after failing that hard...
This shows how little you understand the arguments you're making
which leaves me thinking about pots and kettles.
(*) of course the actual command is a failure too, since that period is a wildcard and no boundary is given either. So even a comment somewhere in a script reading "# by the way, we would never source /etc/init.d/functions" would mistakenly be included in your already pointless measurement. For the record, a competent AC would have used
(note the -l) rather than
Not that the result is anything meaningful.
Do a "ls -alSrh /lib/systemd/systemd-* /usr/bin/systemd-*"
Oh well. Thanks for the expert insight. I certainly see now why you hate the CLI.
The argument is 'splitting hairs' because it's getting at the wrong point. The problem with systemd isn't that the init scripts (or unit files) depend on systemd......
And noone said that.
If you click "Parent" often enough you'll arrive at a +5 Insightful comment quoted below:
Systemd is a collection of small executables each with a precise goal, in line with the UNIX philosophy. /lib/systemd/systemd-* /usr/bin/systemd-*" if you want to verify this fact.
Do a "ls -alSrh
I've spent enough time "arguing" with this troll, so I'll just mock him for "-alSrh" this time. Obviously memorized instead of arrived at by understanding ls(1); why would we want -S and -r? -a makes absolutely no sense in the use case.
Reminds me of a guy who will always use ``grep -nir'', no matter whether he actually wants line numbers, case insensitivity and/or recursion, simply because ``grep -nir'' was the first usage of grep he saw, and he decided to just memorize it because at some point it was useful, rather than finding out what he actually did and what more there is. jcdr with his ``ls -alSrh'' strikes me as being of the same kind. Loud and clueless.
No magnetron?
The point is not so trivial because init scripts allegedly depending on init was brought up as an analogy to systemd-younameit depending on systemd, which was in turn used to point out that systemd is modular and therefore quite the UNIX way. It doesn't get much wronger.
Also, splitting hairs is surprisingly nontrivial ;)