Many terminal emulators include the option of creating or not creating a TTY to attach to when you run them.
Start a terminal and type w. You might find a pts terminal for each terminal you are running.
Probably you would. Some software doesn't work right if it doesn't have a controlling TTY - and some software specifically talks to its controlling TTY as opposed to stdin/stdout in order to bypass pipeline redirection mechanisms.
(For instance: terminal applications might check for a controlling TTY before using control codes. "ls" formats its output if stdout is the TTY. "ssh" prints its password prompt (and receives its password input) from the TTY)
A controlling TTY is also required for job control: CTRL-C to kill a process, CTRL-Z to suspend a process, etc. don't work if there's no TTY.
Someone can correct me if I'm wrong, but a TTY includes the separate terminal sessions and particular X Windows session(S) you are in. IE: CTRL+ALT+F1 - CTRL+ALT+Fn
Not "in window" terminal sessions alone.
Honestly, I'm not sure. Certainly it's possible that the X server assumes/dev/tty7 (or whatever) as its controlling TTY - but I don't know if that's actually what happens.
And either way - a processor-intensive job launched directly from the GUI is going to have the same process group as other jobs launched directly from the GUI, unless some piece of code takes action to change the jobs' controlling TTYs.
The whole benefit in this test case presented in the video is derived from the fact that the processor-intensive job (the "make -j64" command) is run in a different process group (the xterm's TTY) from the GUI applications.
Actually it's not a speedup at all. It's a different scheduling approach, which ultimately seems to favour applications that need to be responsive to user input over applications consuming large chunks of cpu-time.
It doesn't even do that.
What it does is create groups of processes according to the controlling TTY. The reason the "make -j64" didn't totally overrun the machine is because all those processes were running in a single group, and all the GUI apps (presumably running with no controlling TTY) were in another group.
If the GUI apps had been launched from the same terminal window as the compile, then (assuming the GUI apps didn't detach themselves from the TTY) they'd be bogged down by the compile. If another app with no controlling TTY was causing the slowdown, that too would cause the GUI apps (with no controlling TTY) to crawl.
Because if you can predict how people are going to react to a certain set of conditions then you have demonstrated mastery over their inferior minds. But you have to call it out, or else no one will know!
Compiling the kernel doesn't prove true userspace improvements, but it does show an improvement with scheduling.
I see. It creates "groups" based on the tty and then tries to even out the CPU utilization between groups. This helps if there is a crazy background process eating up CPU and it might even help control flash crushing system performance a bit.
So basically the improvement here is coming from the fact that the whole make -j64 is being run under one TTY, and hence under one process group. The whole question of what process groups, if any, the windowed programs are in is pretty much incidental in this case, right?
Dante Hicks is just like you. He looooves grape soda.
And despite his low rank, he's actually quite a competent soldier. He'll make a great de-facto leader for the drop team when the sarge buys it and the lieutenant turns out to be an incompetent douche.
That depends, you go to it often enough, and the data it's collected will say "In my personal experience as a vending machine, quite a few people with facial hair and mohawks like iced tea". And then it'll offer you iced tea.
Do you also wear a lot of gold chains and said "I pity the fool" a lot?
Did Mr. T really say "I pity the fool" a lot, or was it just that one time in Rocky III?
I haven't seen, for instance, his old pro wrestling appearances, or his cartoon, or whatever the hell he's doing these days - so I don't actually know if it's actually a catchphrase he used extensively or not. I watched a bunch of "A Team" episodes and he didn't say it even once.
C can be a high level language. In one recent project, I added garbage collection to C and tagged types.
...
There are limitations, of course, because C doesn't give you enough access to the language to tweak the compiler. For instance, you can't teach the compiler to generate code which is aware of your garbage collector.
So all that, and you also have to manually operate your GC? It could be I'm not envisioning this thing but it seems like a bunch of trouble, and without quite all the benefits one would hope for from type-tagged values and GC.
It seems to me that I could do all that, and then write a bunch of C code that explicitly invokes the GC (or do similar in C++ and spare myself a little bit of that stuff) - or I could just link C code into Python or another high-level language. If the point of using a high-level language is for ease of writing my non-performance-critical code, going with the ready-made option seems like the better way to go.
Nothing that isn't at least as easy in any other language I have used. Which of course is why I asked.
If you want this discussion to go anywhere, you're going to have to be more specific. Instead of saying (effectively) "everything about C++ is done better in every other language I've used" you could add "but, for instance..."
If you're not interested in attempting to substantiate your opinion, that's fine: I'll just know not to assign any value to it.
C++ is, to me, a good all-around performer. You can get great performance out of compiled code with readily available compilers on multiple platforms. You can work with it as though it were C for those areas that need to deal with low-level concepts for performance or whatever other reason, but it also provides the organizational framework (namespaces, classes, templates, operator overloads, etc.) that can be used to lend a reasonably high-level feel to the higher levels of a program. I do believe C++ has its shortcomings, but I'm not convinced that any other languages can match its all-around performance at present.
I'd say that functional languages are generally harder than C++. I love 'em, but getting things done is often easier in an imperative language.
I'd say PHP is harder than C++ just because the language is such a mess of inconsistent policies, context-sensitive evaluation of data types, and so on. I'm tempted to say the same of Perl but I really haven't used it as much as PHP.
I love coding in Python but I feel like debugging it, compared to debugging C++, is a nightmare. I love the things you can do with objects and classes in Python: for instance, providing an alternative implementation for the class's namespace-lookup (giving you the ability to define an object's set of members dynamically, in effect, or do things like query an inter-process object's calling interface and then replicate that interface in the interface class you've provided in Python) - but that same power, to assign any type of data to any variable, to subvert the most basic assumptions of how classes work and so on, also means that by the time your program crashes it may be very far from the point of failure.
Do shell scripts count as a programming language? I think those are crazy screwed-up... But maybe they don't count so I'm not going to go into it for now.
But on a day to day basis I find no need for this. GIMP is native-compiled. Firefox is native-compiled. Blender is native-compiled. And so on. If I need to run a program on another machine, I can download another copy of the program compiled for that machine (i.e. x86 vs. x86-64 in my case).
I'm not saying a VM can't be useful, but why do we need it?
It might be worthwhile to explore what it would take to make some variation of Lisp (*cough*sbcl*cough*) a workable choice for modern software developers.
Well, we did a little research* and spoke to some programmers, and our design committee looked at different directions Lisp could be taken to make it more workable for modern developers... We were thinking maybe we could cut down on some of those parentheses.
The issue is the languages themselves. If you have to write all of the performance critical sections in C, why bother using the non C language in the first place?
Because the performance critical sections often account for relatively small portions of the overall program?
The idea is to write what you need to write, and get it done efficiently, by using a high-level language. And then you go back and optimize the 10% of code that gains you 90% of the benefit to be had from optimization.
Objective C is associated with Apple but it's not an apple exclusive. It has the late binding attraction of Java, but the speed of C. It simplifies objects and is easier to write than C++.
Outside of assembly is there anything that isn't easier to write in than C++? Real question.
I'd love to see something utilizing LLVM. I'm not convinced the OSS community has the organizational capability. I'm also not sure GPL people would work on something BSD-licensed. Instead, they'd try to reinvent the wheel, it would go nowhere for years, and nothing would come of it.
It seems to me that organizational capability really is the big issue here...
The GPL vs. BSD thing you mentioned is certainly a part of that. But basically, developing a piece of common infrastructure also requires getting people to use it... That means it either needs to be valuable enough (i.e. serving an important, known need that's scarcely met by other packages) that people will want to use it, or there needs to be a system of leadership that allows the proponents of the package to get it entrenched. The former is very hard to accomplish for technical reasons (making something that people need, making sure they know they need it, making it good enough that they'll know it's right for them, inspiring enough confidence that they won't worry it will break or not last), while the latter is hard to accomplish for organizational reasons.(you need to have enough influence to pull it off.)
Another computer type who thinks "3D printing" is magic. It's not.
The technology is over 20 years old now. It has become better, and you can now get plastics with some structural strength. But it's very slow. It takes hours to make simple parts. You can make plastic parts for about 100x the cost of making them in quantity by injection molding. Making simple brackets this way isn't cost-effective. When you look at the design of the "Mendel" RepRap machine, the few parts that are actually made with RepRap could be made by injection molding, probably for about $5 a set in quantities of a few thousand. Most of the machine is electronics, motors, steel shafts, and belts, none of which RepRap can make.
Well, yes... But these things change. I think that's the point of the article. There will come a point in time where machines like this are much cheaper, more common, and with greater functionality. There is going to come a point in time when high-quality color, multi-material 3-D printing is actually a common household item. As this happens, the impact of end-users printing things themselves will start to be felt by other industries, and they'll fight for aggressive copyright protection in this domain. That's the battle the home-fabbers are gearing up for.
As it is now, machines like RepRap are definitely niche hobbyist items. And, as you say, despite efforts to make the machine self-replicating, there are critical components it can't reproduce. And the results are fairly crude. But the list of parts that the machine itself can print for its own construction does include some specialized stuff, like the feeder. So although the machine isn't "self-replicating", the fact that key components were designed to be printable means that it's much easier to produce additional copies of the machine than it would be otherwise - especially as the design is further improved (and the design of these key components changes again...)
Slashdot Mirror
Many terminal emulators include the option of creating or not creating a TTY to attach to when you run them.
Start a terminal and type w. You might find a pts terminal for each terminal you are running.
Probably you would. Some software doesn't work right if it doesn't have a controlling TTY - and some software specifically talks to its controlling TTY as opposed to stdin/stdout in order to bypass pipeline redirection mechanisms.
(For instance: terminal applications might check for a controlling TTY before using control codes. "ls" formats its output if stdout is the TTY. "ssh" prints its password prompt (and receives its password input) from the TTY)
A controlling TTY is also required for job control: CTRL-C to kill a process, CTRL-Z to suspend a process, etc. don't work if there's no TTY.
Someone can correct me if I'm wrong, but a TTY includes the separate terminal sessions and particular X Windows session(S) you are in. IE: CTRL+ALT+F1 - CTRL+ALT+Fn
Not "in window" terminal sessions alone.
Honestly, I'm not sure. Certainly it's possible that the X server assumes /dev/tty7 (or whatever) as its controlling TTY - but I don't know if that's actually what happens.
And either way - a processor-intensive job launched directly from the GUI is going to have the same process group as other jobs launched directly from the GUI, unless some piece of code takes action to change the jobs' controlling TTYs.
The whole benefit in this test case presented in the video is derived from the fact that the processor-intensive job (the "make -j64" command) is run in a different process group (the xterm's TTY) from the GUI applications.
Actually it's not a speedup at all. It's a different scheduling approach, which ultimately seems to favour applications that need to be responsive to user input over applications consuming large chunks of cpu-time.
It doesn't even do that.
What it does is create groups of processes according to the controlling TTY. The reason the "make -j64" didn't totally overrun the machine is because all those processes were running in a single group, and all the GUI apps (presumably running with no controlling TTY) were in another group.
If the GUI apps had been launched from the same terminal window as the compile, then (assuming the GUI apps didn't detach themselves from the TTY) they'd be bogged down by the compile. If another app with no controlling TTY was causing the slowdown, that too would cause the GUI apps (with no controlling TTY) to crawl.
I think I've got that correct...
tired "inb4" bullshit...
why?
Because if you can predict how people are going to react to a certain set of conditions then you have demonstrated mastery over their inferior minds. But you have to call it out, or else no one will know!
Compiling the kernel doesn't prove true userspace improvements, but it does show an improvement with scheduling.
I see. It creates "groups" based on the tty and then tries to even out the CPU utilization between groups. This helps if there is a crazy background process eating up CPU and it might even help control flash crushing system performance a bit.
So basically the improvement here is coming from the fact that the whole make -j64 is being run under one TTY, and hence under one process group. The whole question of what process groups, if any, the windowed programs are in is pretty much incidental in this case, right?
Apple whore.
Baltimore!
Dante Hicks is just like you. He looooves grape soda.
And despite his low rank, he's actually quite a competent soldier. He'll make a great de-facto leader for the drop team when the sarge buys it and the lieutenant turns out to be an incompetent douche.
That depends, you go to it often enough, and the data it's collected will say "In my personal experience as a vending machine, quite a few people with facial hair and mohawks like iced tea". And then it'll offer you iced tea.
Do you also wear a lot of gold chains and said "I pity the fool" a lot?
Did Mr. T really say "I pity the fool" a lot, or was it just that one time in Rocky III?
I haven't seen, for instance, his old pro wrestling appearances, or his cartoon, or whatever the hell he's doing these days - so I don't actually know if it's actually a catchphrase he used extensively or not. I watched a bunch of "A Team" episodes and he didn't say it even once.
First thing this story reminded me of was the vending machines in Macross: they actually follow you around trying to get you to buy things...
C can be a high level language. In one recent project, I added garbage collection to C and tagged types.
There are limitations, of course, because C doesn't give you enough access to the language to tweak the compiler. For instance, you can't teach the compiler to generate code which is aware of your garbage collector.
So all that, and you also have to manually operate your GC? It could be I'm not envisioning this thing but it seems like a bunch of trouble, and without quite all the benefits one would hope for from type-tagged values and GC.
It seems to me that I could do all that, and then write a bunch of C code that explicitly invokes the GC (or do similar in C++ and spare myself a little bit of that stuff) - or I could just link C code into Python or another high-level language. If the point of using a high-level language is for ease of writing my non-performance-critical code, going with the ready-made option seems like the better way to go.
Nothing that isn't at least as easy in any other language I have used. Which of course is why I asked.
If you want this discussion to go anywhere, you're going to have to be more specific. Instead of saying (effectively) "everything about C++ is done better in every other language I've used" you could add "but, for instance..."
If you're not interested in attempting to substantiate your opinion, that's fine: I'll just know not to assign any value to it.
C++ is, to me, a good all-around performer. You can get great performance out of compiled code with readily available compilers on multiple platforms. You can work with it as though it were C for those areas that need to deal with low-level concepts for performance or whatever other reason, but it also provides the organizational framework (namespaces, classes, templates, operator overloads, etc.) that can be used to lend a reasonably high-level feel to the higher levels of a program. I do believe C++ has its shortcomings, but I'm not convinced that any other languages can match its all-around performance at present.
I'd say that functional languages are generally harder than C++. I love 'em, but getting things done is often easier in an imperative language.
I'd say PHP is harder than C++ just because the language is such a mess of inconsistent policies, context-sensitive evaluation of data types, and so on. I'm tempted to say the same of Perl but I really haven't used it as much as PHP.
I love coding in Python but I feel like debugging it, compared to debugging C++, is a nightmare. I love the things you can do with objects and classes in Python: for instance, providing an alternative implementation for the class's namespace-lookup (giving you the ability to define an object's set of members dynamically, in effect, or do things like query an inter-process object's calling interface and then replicate that interface in the interface class you've provided in Python) - but that same power, to assign any type of data to any variable, to subvert the most basic assumptions of how classes work and so on, also means that by the time your program crashes it may be very far from the point of failure.
Do shell scripts count as a programming language? I think those are crazy screwed-up... But maybe they don't count so I'm not going to go into it for now.
Compile once, run anywhere.
But on a day to day basis I find no need for this. GIMP is native-compiled. Firefox is native-compiled. Blender is native-compiled. And so on. If I need to run a program on another machine, I can download another copy of the program compiled for that machine (i.e. x86 vs. x86-64 in my case).
I'm not saying a VM can't be useful, but why do we need it?
It might be worthwhile to explore what it would take to make some variation of Lisp (*cough*sbcl*cough*) a workable choice for modern software developers.
Well, we did a little research* and spoke to some programmers, and our design committee looked at different directions Lisp could be taken to make it more workable for modern developers... We were thinking maybe we could cut down on some of those parentheses.
(* Not actually true)
We do not need a language-de-franca. We need a virtual-machine-de-franca.
Why do we need a VM, again?
The issue is the languages themselves. If you have to write all of the performance critical sections in C, why bother using the non C language in the first place?
Because the performance critical sections often account for relatively small portions of the overall program?
The idea is to write what you need to write, and get it done efficiently, by using a high-level language. And then you go back and optimize the 10% of code that gains you 90% of the benefit to be had from optimization.
I'm not arrogant enough to tack that on via FTFY
And thank you for that
So what is Oracle's past history with standardized languages that they have significant control over? I know Microsoft has none
Well, it's not standardized, I think, but there is BASIC...
Objective C is associated with Apple but it's not an apple exclusive. It has the late binding attraction of Java, but the speed of C. It simplifies objects and is easier to write than C++.
Outside of assembly is there anything that isn't easier to write in than C++? Real question.
What's so difficult about C++?
I'd love to see something utilizing LLVM. I'm not convinced the OSS community has the organizational capability. I'm also not sure GPL people would work on something BSD-licensed. Instead, they'd try to reinvent the wheel, it would go nowhere for years, and nothing would come of it.
It seems to me that organizational capability really is the big issue here...
The GPL vs. BSD thing you mentioned is certainly a part of that. But basically, developing a piece of common infrastructure also requires getting people to use it... That means it either needs to be valuable enough (i.e. serving an important, known need that's scarcely met by other packages) that people will want to use it, or there needs to be a system of leadership that allows the proponents of the package to get it entrenched. The former is very hard to accomplish for technical reasons (making something that people need, making sure they know they need it, making it good enough that they'll know it's right for them, inspiring enough confidence that they won't worry it will break or not last), while the latter is hard to accomplish for organizational reasons.(you need to have enough influence to pull it off.)
Another computer type who thinks "3D printing" is magic. It's not.
The technology is over 20 years old now. It has become better, and you can now get plastics with some structural strength. But it's very slow. It takes hours to make simple parts.
You can make plastic parts for about 100x the cost of making them in quantity by injection molding. Making simple brackets this way isn't
cost-effective. When you look at the design of the "Mendel" RepRap machine, the few parts that are actually made with RepRap could be made by injection molding, probably for about $5 a set in quantities of a few thousand. Most of the machine is electronics, motors, steel shafts, and belts, none of which RepRap can make.
Well, yes... But these things change. I think that's the point of the article. There will come a point in time where machines like this are much cheaper, more common, and with greater functionality. There is going to come a point in time when high-quality color, multi-material 3-D printing is actually a common household item. As this happens, the impact of end-users printing things themselves will start to be felt by other industries, and they'll fight for aggressive copyright protection in this domain. That's the battle the home-fabbers are gearing up for.
As it is now, machines like RepRap are definitely niche hobbyist items. And, as you say, despite efforts to make the machine self-replicating, there are critical components it can't reproduce. And the results are fairly crude. But the list of parts that the machine itself can print for its own construction does include some specialized stuff, like the feeder. So although the machine isn't "self-replicating", the fact that key components were designed to be printable means that it's much easier to produce additional copies of the machine than it would be otherwise - especially as the design is further improved (and the design of these key components changes again...)
I'm gonna rouse her like Bowser!
In da poopa like Koopa!
Concerning this new patent request, I'll see you in court! It's on like Donkey Kong®!!!
Trademark. Not patent.
As in weally wacist.
Just what we need, someone spreading FUD on a /. discussion.
Nicely done... Arthur Q. Bryan would be proud!
I sort of wish he had succeeded, if only so I could turn in my old boss for infringement. :(
What, you mean your boss didn't use some kind of euphemism? "We're going to have to let you go", etc.?
"I Nintenhoe'd that shit!"?
Up, up, down, down, left, right, left, right, B, A
You're thinking of Konami.