If your friend really had a disruptor pistol, I think he could have gotten on the plane just fine without breaking it down. All he'd have to do would be to wave his hands and say, "There is no pistol" to the TSA agents.
Nah, this guy wasn't really any kind of a charmer. In fact, he seems to go through life generally disagreeable and pissed off, except when he's drunk and partying all rowdy-like. If the TSA guys had given him any trouble he'd probably retort with some kind of "kill you where you stand" comment, which of course would just get him in more trouble. So I guess he was being uncharacteristically clear-thinking in his decision to resort to this kind of subterfuge.
Various distributions (Debian, and I think Ubuntu as well) use it by default as/bin/sh - there's a Debian policy that states you can't count on/bin/sh providing features outside of the POSIX shell standard anyway, so for the various shell scripts that use/bin/sh, an efficient, simple implementation like dash is a good choice.
I think the distros still choose a more comfortable shell as the default login shell, mind you...
That's just a matter of choosing the right tool for the job.
Bash is (as POSIX shells go) very full-featured with a bunch of enhancements (nonstandard extensions) for use in scripting and various niceties for interactive use. It's one of several shells these days that are commonly accepted as good choices for login shells.
However, quite a lot of shell scripts on a typical system don't need or use bash extensions. (And Debian policy is that shell scripts that are interpreted with/bin/sh should not use any non-POSIX extensions) A shell that's not so rich in features, but rather written with the goal of providing a quick and compact implementation of the standard is a better choice for these shell scripts. If switching/bin/sh to point at dash produces a noticeable improvement in boot-time, that justifies dash's existence on the system. Interactive command history (via readline), tab completion, associative arrays, built in regex, and so on justify bash.
As for socialism, you have no more right to Take the product of my body (i.e. money) then you can force me to pick cotton in a field and call you master. It's theft of labor. It's a milder form of slavery. I work; you take.
Are you going to move to that one country where nobody has to pay any taxes?
Even if the first option does exclude all terrorist based plane deaths. Boring old aircraft crashes are still far more likely to "kill" you.
In fact, I quite agree. But changing the interpretation of the question to reflect the way people actually interpret it brings that answer down from "flatly impossible, logical contradiction" to the realm of merely "unlikely".
I think grouping processes by controlling TTY isn't a really sensible strategy in an age when a lot of our software doesn't even have any use for a TTY.
Perhaps; but what of the possibility of scheduling groups of processes, where "group" is defined differently? If nothing else, this patch could lead the way to being able to schedule "process groups" where the partitioning into groups is done differently (eg, background services vs user apps, foreground window vs background window, etc).
Yeah, one of the things I missed in my first appraisal of this patch is that it's a starting point, and that they're planning to add more heuristics to the implementation of "auto process grouping" in the future.
An implementation of auto process groups based only on controlling TTY seems very limited given how much people do these days without a TTY device attached... But if you take that as just one of a set of heuristics - suddenly it makes a lot more sense...
Though I still have some concerns about the idea. It assumes a particular model of TTY usage. If a distinct controlling TTY always means a new process group, that could cause problems if a piece of software makes more extensive use of PTY devices.
The ninth amendment says nothing about airplanes. It say you may have some other rights. One might just as well interrupt that as having a right not to have airplanes run into your buildings. The fourth amendment says the government can't force you to submit to a search. They're not forcing you. You don't HAVE to get on that plane. They're not going to send you jail if you don't submit to the search, they're not letting you get on the plane.
That's just a means of weaseling their way around the literal interpretation of the law. If you can't force someone to submit to a search, you make it very, very painful for them to get around it. You're not forcing them, so it's OK - never mind the fact that you've made things so unreasonably complicated in the case that people don't submit that the practical effect is the same as if you had. They come up with a loophole and that's just OK with you?
The risk of dying in a plane crash is tiny to start with -- about 1 in 11 million -- and the risk of being the victim of a terrorist attack is smaller still
Consider the following situation: Henry is a traveller in the United States, who is about to go on a flight to New York. Is it more likely that he would die from a plane crash, or die from a plane crash caused by a terrorist action.
The quirky thing about how humans think is that if you set up a question like this, many people will pick the second option, even though it is more specific.
If you present the question like that, it sounds like you're presenting two mutually-exclusive options, even though (as phrased) they're not. I think there's a natural tendency to assume the first option is meant to exclude the second. Hence it's kind of a trick question.
The worst part is when the TSA goon sniffs his fingers after fondling people's genitals. They must be sniffing for explosive residue.
Hentai provides the perfect answer:
If you are a guy, be sure to let them know that you avoided bathing for weeks, because you know there's nothing they like better than a dirty, sweaty guy's body funk. When the agent begins touching you, point out that they are, in fact, a dirty whore.
If you are a girl (and you are kinky), show up to the enhanced pat-down in shibari bondage with vibrators in and running. Make it clear that you are looking forward to this sexual experience.
Unpleasant... yes, effective? No. I was recently made aware of someone taking a hunting knife (not a $20 swiss army, but an actual knife) through security with the help of steel-toed boots.
That's nothing - a friend of mine got an entire disruptor pistol through security by breaking it down into components and disguising them as fashion accessories...
Re:What's the deal with the rush of TSA stories re
on
TSA Pats Down 3-Year-Old
·
· Score: 3, Funny
The rule works in principle, but we all know the part about best-laid plans.
"Emacs: launched from window manager, therefore inherits window manager's process group."
Maybe I am missing something. The terminal used for the build is launched from the Window Manager. What is the difference?
The difference is that the terminal creates a TTY session (interactive command shells almost always have a TTY, as it's required for job control and window resize notifications and other things), and therefore (under the auto-grouping process scheduler) a separate process group. The build started in the terminal window could spawn a thousand processes, and they'd all wind up in that same process group.
The concept of process groups is rather new to me (it's kind of a new thing, right?) and so my understanding on some of these points may be incorrect: but my understanding is that this scheduler helps if and only if that big compilation job winds up in its own process group. The kernel periodically context-switches away from the whole process group to do other things. That's where the benefit comes from: if a 64-process build were running at the same time as a video player (maybe itself 2 or 3 processes), that video player would probably get less than 1/30 of the total CPU resources. The fact that the compilation is using more processes effectively gives it more priority. But if those 64 processes were part of a single group, and the scheduler is servicing groups with more or less even priority, then that video player (assuming there's just the two groups, and nothing else is in the video player's group) gets to claim about half the total CPU resources...
Creating a terminal window creates a new process group - and the process groups are what causes things to behave differently under this patch.
"I don't think that's something one should take for granted. We all make mistakes. And I think it was mentioned in the mailing list that this was an implementation of an idea Linus came up with in the first place... If so, it's natural he'd stand behind it."
Actually Linus' said he wasn't expecting much and was quite surprised. This isn't some theoretical improvement. People in the real world are reporting excellent results left and right. Empirical evidence isn't influenced by bias.
Empirical evidence can be influenced by bias. For instance, the bias that goes into selecting your test cases... The empirical evidence cited on the mailing list was all based on this same single kind of test - a big job running on a TTY. One flawed test case with good results, plus a lot of anecdotal evidence from people I don't know does not convince me.
I've been reading the mailing list messages a bit more and one bit I'd missed previously is that this is that this is the starting point, and other heuristics will become a part of auto-grouping later on. So from that perspective the situation seems rather more promising.
""At this point I'm feeling a bit skeptical. This one particular test case works because the build process winds up on a different controlling TTY. But what if the compile had been started, say, from within Emacs (launched from the window manager)?"
I don't think this would change a thing - other than maybe making emacs itself less responsive
But don't you see? In this case:
Emacs: launched from window manager, therefore inherits window manager's process group. Big-ass compile job: launched from Emacs without a controlling TTY, therefore inherits window manager's process group. Firefox: launched from window manager, therefore inherits window manager's process group. Video player: launched from window manager etc. etc.
The result in this case is that the big compile job isn't conveniently landed into a separate process group. Not only does the user (for reasons that won't be apparent to someone who doesn't know how the scheduler works) not get the performance benefit, but in fact the performance of their desktop applications will be degraded as a result of being stuffed into the same group as the compile job.
Blah blah blah let's bash Emacs. Whatever. Still this TTY-based grouping does nothing for processes that don't rely on TTYs for anything at all... And it could put undue prioritization on tasks just because they happen to have a unique controlling TTY.
"Compiling the kernel isn't a useful benchmark. How well does it deal with running Adobe Air?"
Obviously you've never compiled a kernel passing -j64 to the make process. If you had, you would know that all your CPUs would be pegged (indeed -j7 pegs all 8 cores on my laptop.) Of course that is not the benchmark part. The point is that with an "all your processors are belong to kernel build" condition, group scheduling allows there to be essentially no perceived slowdown for interactive GUI/Window manager based computing.
If I'm building a kernel with -j64, is desktop performance during that process really my top priority? And how does this scheduler change affect the performance of that build?
You probably should have figured out that you were missing something when Linus Torvalds didn't object to the benchmark and the results. Seriously, this is a major point to understand: When it comes to the kernel, in a fight between your knowledge and Linus', Linus wins.
I don't think that's something one should take for granted. We all make mistakes. And I think it was mentioned in the mailing list that this was an implementation of an idea Linus came up with in the first place... If so, it's natural he'd stand behind it.
At this point I'm feeling a bit skeptical. This one particular test case works because the build process winds up on a different controlling TTY. But what if the compile had been started, say, from within Emacs (launched from the window manager)? If Emacs has a controlling TTY in that case, it's the same controlling TTY (and thus, same process group) as Firefox and glxgears. Compiles kicked off from within Emacs don't get a separate TTY. Or, as someone else mentioned, what if another processor-intensive job (like a video encode, a Blender render, etc.) were kicked off from a GUI app not launched from an xterm? This patch wouldn't do anything for you in that case.
Alternately, what if the other applications had also been launched from the terminal window? They'd all wind up in the same process group, unless they detached themselves from the TTY.
This patch does wonders for preventing big jobs from messing up UI responsiveness if that big job is on a separate process group. But it seems like there's all kinds of common cases where that wouldn't wind up being the case.
It seems to me that Linus is latching on to this idea because it suits the way he works: which is fine - but that doesn't mean that it's going to be an important and useful solution for the rest of us. This is why it's important to consider whether the test case is really typical of what other people are doing with the system. If you don't do that, then it skews your whole perspective of how useful this patch really is. Linus is taking the attitude that this patch has been shown to work well, and therefore discussing the merits of the approach is meaningless. I disagree. Looking at this thing it seems like they looked at one atypical use case and, based on that, declared that the patch works miracles.
I think grouping processes by controlling TTY isn't a really sensible strategy in an age when a lot of our software doesn't even have any use for a TTY... I agree in principle with the idea that we should measure the merits of a scheduler strategy in terms of results, not academic merit... But the test cases have to be representative of typical use cases, and they have to cover all the common ones, or else they're meaningless. I really think Linus has missed that here.
Slashdot Mirror
Unknown to Speed, Reader X is actually Rex Reader, his estranged older brother in disguise!
Actually there is a country where nobody has to pay taxes - Somalia! Say YES to Anarchy!
Yeah! I'm gonna go there, find the One Piece and become king of the pirates!
If your friend really had a disruptor pistol, I think he could have gotten on the plane just fine without breaking it down. All he'd have to do would be to wave his hands and say, "There is no pistol" to the TSA agents.
Nah, this guy wasn't really any kind of a charmer. In fact, he seems to go through life generally disagreeable and pissed off, except when he's drunk and partying all rowdy-like. If the TSA guys had given him any trouble he'd probably retort with some kind of "kill you where you stand" comment, which of course would just get him in more trouble. So I guess he was being uncharacteristically clear-thinking in his decision to resort to this kind of subterfuge.
Uh... Who exactly is using Dash?
Various distributions (Debian, and I think Ubuntu as well) use it by default as /bin/sh - there's a Debian policy that states you can't count on /bin/sh providing features outside of the POSIX shell standard anyway, so for the various shell scripts that use /bin/sh, an efficient, simple implementation like dash is a good choice.
I think the distros still choose a more comfortable shell as the default login shell, mind you...
The use of Dash as the default shell over Bash
That's just a matter of choosing the right tool for the job.
Bash is (as POSIX shells go) very full-featured with a bunch of enhancements (nonstandard extensions) for use in scripting and various niceties for interactive use. It's one of several shells these days that are commonly accepted as good choices for login shells.
However, quite a lot of shell scripts on a typical system don't need or use bash extensions. (And Debian policy is that shell scripts that are interpreted with /bin/sh should not use any non-POSIX extensions) A shell that's not so rich in features, but rather written with the goal of providing a quick and compact implementation of the standard is a better choice for these shell scripts. If switching /bin/sh to point at dash produces a noticeable improvement in boot-time, that justifies dash's existence on the system. Interactive command history (via readline), tab completion, associative arrays, built in regex, and so on justify bash.
And I'm pretty sure that 24% of desktop computers are not Linux.
Oh, it's probably more than that... I mean, I'm a fan of Linux but let's be realistic... 76% market share on the desktop? No way...
Drago: If it dies, it dies.
I don't hate Balboa. I pity the fool.
Thanks for the correction.
As for socialism, you have no more right to Take the product of my body (i.e. money) then you can force me to pick cotton in a field and call you master. It's theft of labor. It's a milder form of slavery. I work; you take.
Are you going to move to that one country where nobody has to pay any taxes?
Even if the first option does exclude all terrorist based plane deaths. Boring old aircraft crashes are still far more likely to "kill" you.
In fact, I quite agree. But changing the interpretation of the question to reflect the way people actually interpret it brings that answer down from "flatly impossible, logical contradiction" to the realm of merely "unlikely".
Perhaps; but what of the possibility of scheduling groups of processes, where "group" is defined differently? If nothing else, this patch could lead the way to being able to schedule "process groups" where the partitioning into groups is done differently (eg, background services vs user apps, foreground window vs background window, etc).
Yeah, one of the things I missed in my first appraisal of this patch is that it's a starting point, and that they're planning to add more heuristics to the implementation of "auto process grouping" in the future.
An implementation of auto process groups based only on controlling TTY seems very limited given how much people do these days without a TTY device attached... But if you take that as just one of a set of heuristics - suddenly it makes a lot more sense...
Though I still have some concerns about the idea. It assumes a particular model of TTY usage. If a distinct controlling TTY always means a new process group, that could cause problems if a piece of software makes more extensive use of PTY devices.
That's the best you could come up with?
Maybe you'll have more luck once you reach preschool.
I've gone all these years without schooling, why start now?
But alas! We're stuck with this accursed monarchy!
Don't blame me, I voted for Kodos.
The ninth amendment says nothing about airplanes. It say you may have some other rights. One might just as well interrupt that as having a right not to have airplanes run into your buildings. The fourth amendment says the government can't force you to submit to a search. They're not forcing you. You don't HAVE to get on that plane. They're not going to send you jail if you don't submit to the search, they're not letting you get on the plane.
That's just a means of weaseling their way around the literal interpretation of the law. If you can't force someone to submit to a search, you make it very, very painful for them to get around it. You're not forcing them, so it's OK - never mind the fact that you've made things so unreasonably complicated in the case that people don't submit that the practical effect is the same as if you had. They come up with a loophole and that's just OK with you?
The risk of dying in a plane crash is tiny to start with -- about 1 in 11 million -- and the risk of being the victim of a terrorist attack is smaller still
Consider the following situation: Henry is a traveller in the United States, who is about to go on a flight to New York. Is it more likely that he would die from a plane crash, or die from a plane crash caused by a terrorist action.
The quirky thing about how humans think is that if you set up a question like this, many people will pick the second option, even though it is more specific.
If you present the question like that, it sounds like you're presenting two mutually-exclusive options, even though (as phrased) they're not. I think there's a natural tendency to assume the first option is meant to exclude the second. Hence it's kind of a trick question.
When they treat you like cattle, it's time to ask whose cattle you are
Well, there's this burn scar on my ass that says "Benevolent Robot Overlords"... I wonder what that's all about...
The worst part is when the TSA goon sniffs his fingers after fondling people's genitals.
They must be sniffing for explosive residue.
Hentai provides the perfect answer:
If you are a guy, be sure to let them know that you avoided bathing for weeks, because you know there's nothing they like better than a dirty, sweaty guy's body funk. When the agent begins touching you, point out that they are, in fact, a dirty whore.
If you are a girl (and you are kinky), show up to the enhanced pat-down in shibari bondage with vibrators in and running. Make it clear that you are looking forward to this sexual experience.
Unpleasant... yes, effective? No. I was recently made aware of someone taking a hunting knife (not a $20 swiss army, but an actual knife) through security with the help of steel-toed boots.
That's nothing - a friend of mine got an entire disruptor pistol through security by breaking it down into components and disguising them as fashion accessories...
The rule works in principle, but we all know the part about best-laid plans.
They usually involve your mom?
Maybe I am missing something. The terminal used for the build is launched from the Window Manager. What is the difference?
The difference is that the terminal creates a TTY session (interactive command shells almost always have a TTY, as it's required for job control and window resize notifications and other things), and therefore (under the auto-grouping process scheduler) a separate process group. The build started in the terminal window could spawn a thousand processes, and they'd all wind up in that same process group.
The concept of process groups is rather new to me (it's kind of a new thing, right?) and so my understanding on some of these points may be incorrect: but my understanding is that this scheduler helps if and only if that big compilation job winds up in its own process group. The kernel periodically context-switches away from the whole process group to do other things. That's where the benefit comes from: if a 64-process build were running at the same time as a video player (maybe itself 2 or 3 processes), that video player would probably get less than 1/30 of the total CPU resources. The fact that the compilation is using more processes effectively gives it more priority. But if those 64 processes were part of a single group, and the scheduler is servicing groups with more or less even priority, then that video player (assuming there's just the two groups, and nothing else is in the video player's group) gets to claim about half the total CPU resources...
Creating a terminal window creates a new process group - and the process groups are what causes things to behave differently under this patch.
It's natural that Google wouldn't flinch. On the contrary, they were probably quite courteous.
"Thanks, Facebook, but we have plenty of blow already!"
I find their music uninteresting and the hype annoying.
That's because you're too young to be able to see what an effect the Beatles had on music and indeed, society (actually, societies) in general.
Yeah, they even appeared on Doctor Who!
I'm pretty sure that was a reference to MiB.
I think they also did that joke on Seaquest DSV...
Actually Linus' said he wasn't expecting much and was quite surprised. This isn't some theoretical improvement. People in the real world are reporting excellent results left and right. Empirical evidence isn't influenced by bias.
Empirical evidence can be influenced by bias. For instance, the bias that goes into selecting your test cases... The empirical evidence cited on the mailing list was all based on this same single kind of test - a big job running on a TTY. One flawed test case with good results, plus a lot of anecdotal evidence from people I don't know does not convince me.
I've been reading the mailing list messages a bit more and one bit I'd missed previously is that this is that this is the starting point, and other heuristics will become a part of auto-grouping later on. So from that perspective the situation seems rather more promising.
I don't think this would change a thing - other than maybe making emacs itself less responsive
But don't you see? In this case:
Emacs: launched from window manager, therefore inherits window manager's process group.
Big-ass compile job: launched from Emacs without a controlling TTY, therefore inherits window manager's process group.
Firefox: launched from window manager, therefore inherits window manager's process group.
Video player: launched from window manager etc. etc.
The result in this case is that the big compile job isn't conveniently landed into a separate process group. Not only does the user (for reasons that won't be apparent to someone who doesn't know how the scheduler works) not get the performance benefit, but in fact the performance of their desktop applications will be degraded as a result of being stuffed into the same group as the compile job.
Blah blah blah let's bash Emacs. Whatever. Still this TTY-based grouping does nothing for processes that don't rely on TTYs for anything at all... And it could put undue prioritization on tasks just because they happen to have a unique controlling TTY.
Obviously you've never compiled a kernel passing -j64 to the make process. If you had, you would know that all your CPUs would be pegged (indeed -j7 pegs all 8 cores on my laptop.) Of course that is not the benchmark part. The point is that with an "all your processors are belong to kernel build" condition, group scheduling allows there to be essentially no perceived slowdown for interactive GUI/Window manager based computing.
If I'm building a kernel with -j64, is desktop performance during that process really my top priority? And how does this scheduler change affect the performance of that build?
You probably should have figured out that you were missing something when Linus Torvalds didn't object to the benchmark and the results. Seriously, this is a major point to understand: When it comes to the kernel, in a fight between your knowledge and Linus', Linus wins.
I don't think that's something one should take for granted. We all make mistakes. And I think it was mentioned in the mailing list that this was an implementation of an idea Linus came up with in the first place... If so, it's natural he'd stand behind it.
At this point I'm feeling a bit skeptical. This one particular test case works because the build process winds up on a different controlling TTY. But what if the compile had been started, say, from within Emacs (launched from the window manager)? If Emacs has a controlling TTY in that case, it's the same controlling TTY (and thus, same process group) as Firefox and glxgears. Compiles kicked off from within Emacs don't get a separate TTY. Or, as someone else mentioned, what if another processor-intensive job (like a video encode, a Blender render, etc.) were kicked off from a GUI app not launched from an xterm? This patch wouldn't do anything for you in that case.
Alternately, what if the other applications had also been launched from the terminal window? They'd all wind up in the same process group, unless they detached themselves from the TTY.
This patch does wonders for preventing big jobs from messing up UI responsiveness if that big job is on a separate process group. But it seems like there's all kinds of common cases where that wouldn't wind up being the case.
It seems to me that Linus is latching on to this idea because it suits the way he works: which is fine - but that doesn't mean that it's going to be an important and useful solution for the rest of us. This is why it's important to consider whether the test case is really typical of what other people are doing with the system. If you don't do that, then it skews your whole perspective of how useful this patch really is. Linus is taking the attitude that this patch has been shown to work well, and therefore discussing the merits of the approach is meaningless. I disagree. Looking at this thing it seems like they looked at one atypical use case and, based on that, declared that the patch works miracles.
I think grouping processes by controlling TTY isn't a really sensible strategy in an age when a lot of our software doesn't even have any use for a TTY... I agree in principle with the idea that we should measure the merits of a scheduler strategy in terms of results, not academic merit... But the test cases have to be representative of typical use cases, and they have to cover all the common ones, or else they're meaningless. I really think Linus has missed that here.
But 400 lines of code in the subject line would make it 2x faster! LOC is the #1 metric for programming.
As a(n) UBUNTU USER I want to VIDEO PLAY MORE BETTER because CARTOONS IS SERIOUS BUSINESS