While are you are correct in saying that a limited subset of users should be permitted to run the compiler, that subset should never be the superuser. Compilers have security holes too,
and gcc has been no exception. (was it 2.7 or 2.8? don't recall, too tired)
The same keystroke-for-searching decisions could have been made without any of the Mozilla developers ever hearing about vi.
The more commonly-used commands in vi have been adopted by so many different programs that many people know about / and ?, not from vi, but from something else, like a pager program (less and more are big examples here).
The 60-degree angle, moons, and whatnot
on
Is This Moon Three?
·
· Score: 5, Informative
If you ever study the 'Trojans', you know that there are huge bodies of apparent moonlets that sit on a sixty-degree angle from Jupiter's, directly along Jupiter's orbit from the sun. (They are apparently held in such a strange place by the gravity of Jupiter vs. the gravity of Sol.)
Anytime you have something (Foo) orbiting something else (Bar), i.e., once the requirements of "orbit" are met, there are five points of gravitational equilibrium set up amongst the two bodies. They're called LaGrange points. The last two, L4 and L5, are on Foo's orbit around Bar, sixty degrees ahead of Foo (L4) and sixty degrees behind (L5).
L4 and L5 by themselves, ignoring L1-L3, are often called Trojan points, named for this particular group of satellites.
As for the defintion of moon versus just another satellite in general, I believe it has to do with respective mass ratios, and where the fulcrum point of rotation is between the two bodies. Right now our own moon isn't in a true rotation around us, we're in a sort of dumbbell tumble, and the center of the dumbbell is a bit below the ground.
(Actual astronomers please correct me, I'm on a number of narcotic-containing painkillers right now and could have gotten some words tumbled.)
Current development sources recognize athlon* as a cpu type. So instead of i686-pc-linux-gnu, I tell build gcc for athlon_mp-pc-linux-gnu, and by default it uses the -march and -mcpu options that turn on the Athlon MP extensions like SSE and whatever.
Use "gcc -v" to see what triplet you're using.
This is/not/ in 3.2. I'm not even certain if it's in 3.3.
In 3 years, you've just about filled in the gaps left in your undergrad education. And you're not willing to learn any more about CS, you just want to get into the management role. Okay, here's the only recommendation you need for schooling: with your mindset, it doesn't matter which school you attend.
Every single person I talk to who says they know software management in terms of "processes" reminds me of the Dilbert cartoon: "We improve your software process! We don't know how to do anything, we only know how to do it better!"
(I like how he puts down the "general masters degree in CS" like it's somehow inferior to a program of study which specializes in the latest management fad. Like it's not called a Master's degree for a reason.
I remain skeptical that it would ever work in practice, at least for an open-source produce such as gcc.
The technique works fine and not difficult to do -- as long as it isn't GCC. And the rest of your post assumes that GCC is in use. (How many other compilers are out there which have source available (you mention changing contents of the source code) and are designed to be built by multiple arbitrary compilers (the GCC bootstrap mechanism)?
Of those, how may are meant to be modified by the user? (Where "meant" == "it's possible".)
So, reminding the rest of/. readers that most compilers in use are not gcc (unfortunately), we proceed:
Compilers that detect special semantics would be easy, because you don't know what the semantics are, only I do. My compiler can perform some completely useless action with no side-effects (i.e., you can't detect it), and while compiling itself, would a) realize that its own code is being compiled, and b) throw out the useless actions, like any other optimizing compiler would.
Remember that the special thing being detected doesn't have to be detectable at runtime, only at compile time. That opens the doors much wider.
So, use GCC and prevent this trojan.:-) Otherwise, yes, it's very possible.
...the producer sponsoring the deal said that a chunk of the money would be delivered within the next couple of days. So it looks like the deal is still on.
Hopefully there will be a landing pad fire or something. Pity we'd have to lose good cosmonauts to get rid of the pesky fucker.
So worse case is I don't get the job and then I get brought up on charges of some stupid thing I did in my youth.
When I was being interviewed by the feds, I asked them about some of the questions on the many-page form. Questions of the format, "Have you ever mutilated small children while dropping acid, selling crystal meth, and joining a right-wing militia/religious cult all at the same time?" etc. I asked, "are you actually expecting a "oh sure, all the time" answer? Have you ever gotten a yes answer? Don't people get freaked out that they're shooting themselves in the foot?"
The representative[*] chuckled and pointed out that the answers you give on the form, and during the interviews, are sealed. They cannot by law turn around and bring you up on charges based on how you answered. (They can deny you the job/clearance/position/whatever because you're a meth-smoking nutcase, but they can't trick you into putting yourself in jail.)
[*]Sweet little old lady on the outside, but damn... there is nothing more intimidating than someone who looks like your grandmother staring you in the eye while asking, "Are you now or have you ever been a member of any organization whose stated goal is the violent overthrow of the United States Government?" and no, she's not smiling.
...it's the bind-bogglingly stupid hiring practices in general. And the FBI know it; heck, even this article spends only a little time discussing the physical bit. Most of the article points out other ways in which the FBI shoots themselves in the foot:
[security consultent] Rosenberger added that even if a person were an acceptable job applicant, it would not guarantee that the person would work with computers.
"You won't get a position in computer security until you've worked at least five years on the beat, preferably in physical investigations," Rosenberger said. "They'll grudgingly let you past if you just do forensics, but they feel you really should chase bad guys with a gun before you chase bad guys with a computer."
At some point it will occur to the FBI that people can specialize in a topic before joining.
The dinky little "computer toolkit" I have fro years back has a nice translucent plastic tube, about 3/4" diameter. Holding about fifty screws and jumpers and whatnot right about now. I agree -- they're essential.
...was for a metal dish, with high walls, about six inches across, with a very magnetic base. It sticks to metal, and any screw or latching piece will stick to it. No more building a little pile of tiny screws as I take apart a computer while hoping they don't roll away or I knock them over.
It's for home, but I'm thinking about getting another at work.
It's wierd, when you think about it, that programming is still done in flat text files.
Every compiler vendor who has sold a mainstream language compiler/IDE using a "program database" or some other such approach has tanked. (Note that I mean program database as the primary means of storing the code -- a replacement of flat files, not an addition to them.) So far, it's not really been a technological lack, it's just that programmers don't like it.
I recall reading some papers written by the major language guys a decade ago, and one of the things they all wanted to see was per-function recompilation (instead of per-translation-unit), better program information (like "where is this function used?") and other things that would require a more database-like format. Still hasn't happened except in research environments. (Pity.)
One could argue for programs in HTML, with the code bracketed in XML
One could, but one would be a lunatic.
(I'm too tired to write it all down now, but I'll just summarize by saying that XML is not a silver bullet.)
My coder girlfriend gave me some of that as one of my birthday gifts. Apparently my caffeine tolerance is so high that it's merely like an additional sip of coffee after drinking 5 cups: just not enough to register.
Damn.
She doesn't drink nearly as much caffeinated beverages as I do, though. I'm going to have her try it and see what happens.
They sign contacts that make people have it fixed within a specific time period or they recieve massive compensation.
I work as sysadmin on an Air Force base. We have a commercial support contract with Sun that specifies they get replacement parts to us in 4 hours. The other day a hard drive died, and I had the amusement of writing in the support request, "I know where Sun's headquarters are; get me a new hard drive in 4 hours or I call in an airstrike."
(Then I thought some more about it and erased that sentence. Damn humorless paper-pushers. (So of course it took six hours for the drive to get to me.) Oh well.)
Do we teach theoretical science, or applied science?
You teach by example, and do both. Andrew Koenig and Barbara Moo, two of the prime movers behind C++, wrote a book called Accelerated C++: Pratical Programming by Example, as a new approach to teaching C++.
It absolutely kicks ass. Somebody else on this page commented that you need to learn C before learning C++. Most C++ people disagree; this book proves them correct. It starts with
#include <iostream>
// something went here
int main() {
std::cout << "Hello, World!" <<
std::endl; }
and the first lesson was, "the most important line
in this program is the second one," i.e., the comment. How refreshing is that?
It does not then follow up by diving into the guts of the IOstream library; they simply say, "when you want to send stuff to the screen, use this; when you want to get stuff from the keyboard, use this," and leave the details for later. Even though the IOstream library involves OOP, they don't shove the user's nose in it.
The people I know who have started using this book, and the approach that they advocate, to teach beginning programmers, have all found their students not only picking up the language faster,
but being less frustrated with programming in
general (admit it, we've all been there), and having
a better understanding of what's happening in their code.
(Pointers aren't even introduced until chapter 9 or 10, which means anything that visibly uses pointers
isn't needed until then, either. Very nice.)
Kernighan (the 'g' is silent) is the K in K&R C. He wrote,
Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it.
We would do well to remind students at every opportunity that "clever" may be a complement in back-room business deals, but it's usually spoken with heavy irony in programming.
In addition to explaining all that (and TAOCP is the only place I've ever seen it explained), Knuth goes on to give the translation: Rules of equating and restoring.
Apples and oranges
on
GCC 3.2 Released
·
· Score: 5, Informative
The C++ standard says nothing about ABIs. (Well, there are some layout rules when dealing with POD structs, but nothing about a C++ ABI.)
We're not meeting the C++ standard in two regards (at least I can't think of any more): first, we don't have export for templates. That will largely be a fallout of the precompiled header projects (two or three PCH branches have been in the repository for a long time now; both Apple and Red Hat have been contributing their implementations).
Second, we don't do two-stage name lookup for templates. Which most user don't need to worry about. That will come when the current 15-year-old parser has finished being rewritten (and there are branches doing that already as well).
Also, keep in mind that although the compiler C++ ABI is stable, the C++ library ABI is not. Declaring it stable at this point would be a massively stupid thing to do; there are far too many optimizations to be made still, and those involve changing the ABI. For example, there's a reworking of the memory allocator that currently exists on my whiteboard, and as soon as it gets finished off and checked in, the library ABI will be broken. Vendors already have methods in place for dealing with multiple versions of a library installed; this will be nothing new to them.
An answer from a maintainer
on
GCC 3.2 Released
·
· Score: 5, Informative
Hi. I'm one of the hundred-odd GCC maintainers.
When will they understand that breaking interoperability is not the way to go forward?
Because the idea of backwards compatability never occured to any of us until we read your Insightful post. My God, what a concept! I'll go tell them at once!
Seriously, what makes you think the entire team doesn't already understand this point? Do you think such decisions are made lightly? Go read the archives; they agonized over this for months, and that was before the heavy debating started.
Here's the simple fact: there is a C++ ABI designed for compatability and interoperability. Here's another simple fact: there were bugs in our implementation of the ABI. The choice was to be backwards-compatable with previous GCC 3.1 and incompatable with other vendors implementing the same spec -- which would pretty much defeat the purpose of a common ABI. Or we could fix the bugs and break compatability in a couple of corner cases.
Of course, after all the details are worked out is when all of the geniuses with answers to all of life's problems decide to reveal The One True Solution on/. posts...
Die-hard fans don't need to buy the movie, now or ever.
Die-hard fans didn't need a movie in the first place, because no director anywhere -- skilled as Peter Jackson or not -- could come up with a movie as good as what we've had in our heads since the first time we read Tolkien.
Your comments apply to the die-hard sheep, not the die-hard fans. And those are hardly limited to Tolkien.
Slashdot Mirror
Thank you, try again.
While are you are correct in saying that a limited subset of users should be permitted to run the compiler, that subset should never be the superuser. Compilers have security holes too, and gcc has been no exception. (was it 2.7 or 2.8? don't recall, too tired)
Never do your compiling as root.
The same keystroke-for-searching decisions could have been made without any of the Mozilla developers ever hearing about vi.
The more commonly-used commands in vi have been adopted by so many different programs that many people know about / and ?, not from vi, but from something else, like a pager program (less and more are big examples here).
Anytime you have something (Foo) orbiting something else (Bar), i.e., once the requirements of "orbit" are met, there are five points of gravitational equilibrium set up amongst the two bodies. They're called LaGrange points. The last two, L4 and L5, are on Foo's orbit around Bar, sixty degrees ahead of Foo (L4) and sixty degrees behind (L5).
L4 and L5 by themselves, ignoring L1-L3, are often called Trojan points, named for this particular group of satellites.
As for the defintion of moon versus just another satellite in general, I believe it has to do with respective mass ratios, and where the fulcrum point of rotation is between the two bodies. Right now our own moon isn't in a true rotation around us, we're in a sort of dumbbell tumble, and the center of the dumbbell is a bit below the ground.
(Actual astronomers please correct me, I'm on a number of narcotic-containing painkillers right now and could have gotten some words tumbled.)
Current development sources recognize athlon* as a cpu type. So instead of i686-pc-linux-gnu, I tell build gcc for athlon_mp-pc-linux-gnu, and by default it uses the -march and -mcpu options that turn on the Athlon MP extensions like SSE and whatever.
Use "gcc -v" to see what triplet you're using.
This is /not/ in 3.2. I'm not even certain if it's in 3.3.
When will /. get it through its skull that you don't have to use GCC to build GCC? And in fact, that most people don't use GCC to build GCC?
now you think you're ready to manage us? Oh crap.
In 3 years, you've just about filled in the gaps left in your undergrad education. And you're not willing to learn any more about CS, you just want to get into the management role. Okay, here's the only recommendation you need for schooling: with your mindset, it doesn't matter which school you attend.
Every single person I talk to who says they know software management in terms of "processes" reminds me of the Dilbert cartoon: "We improve your software process! We don't know how to do anything, we only know how to do it better!"
(I like how he puts down the "general masters degree in CS" like it's somehow inferior to a program of study which specializes in the latest management fad. Like it's not called a Master's degree for a reason.
The technique works fine and not difficult to do -- as long as it isn't GCC. And the rest of your post assumes that GCC is in use. (How many other compilers are out there which have source available (you mention changing contents of the source code) and are designed to be built by multiple arbitrary compilers (the GCC bootstrap mechanism)?
Of those, how may are meant to be modified by the user? (Where "meant" == "it's possible".)
So, reminding the rest of /. readers that most compilers in use are not gcc (unfortunately), we proceed:
Compilers that detect special semantics would be easy, because you don't know what the semantics are, only I do. My compiler can perform some completely useless action with no side-effects (i.e., you can't detect it), and while compiling itself, would a) realize that its own code is being compiled, and b) throw out the useless actions, like any other optimizing compiler would.
Remember that the special thing being detected doesn't have to be detectable at runtime, only at compile time. That opens the doors much wider.
So, use GCC and prevent this trojan. :-) Otherwise, yes, it's very possible.
...the producer sponsoring the deal said that a chunk of the money would be delivered within the next couple of days. So it looks like the deal is still on.
Hopefully there will be a landing pad fire or something. Pity we'd have to lose good cosmonauts to get rid of the pesky fucker.
When I was being interviewed by the feds, I asked them about some of the questions on the many-page form. Questions of the format, "Have you ever mutilated small children while dropping acid, selling crystal meth, and joining a right-wing militia/religious cult all at the same time?" etc. I asked, "are you actually expecting a "oh sure, all the time" answer? Have you ever gotten a yes answer? Don't people get freaked out that they're shooting themselves in the foot?"
The representative[*] chuckled and pointed out that the answers you give on the form, and during the interviews, are sealed. They cannot by law turn around and bring you up on charges based on how you answered. (They can deny you the job/clearance/position/whatever because you're a meth-smoking nutcase, but they can't trick you into putting yourself in jail.)
[*]Sweet little old lady on the outside, but damn... there is nothing more intimidating than someone who looks like your grandmother staring you in the eye while asking, "Are you now or have you ever been a member of any organization whose stated goal is the violent overthrow of the United States Government?" and no, she's not smiling.
...it's the bind-bogglingly stupid hiring practices in general. And the FBI know it; heck, even this article spends only a little time discussing the physical bit. Most of the article points out other ways in which the FBI shoots themselves in the foot:
At some point it will occur to the FBI that people can specialize in a topic before joining.
Wow. I've never seen anyone flunk "Intro to Remedial Physics" as fast as you just did.
The dinky little "computer toolkit" I have fro years back has a nice translucent plastic tube, about 3/4" diameter. Holding about fifty screws and jumpers and whatnot right about now. I agree -- they're essential.
...was for a metal dish, with high walls, about six inches across, with a very magnetic base. It sticks to metal, and any screw or latching piece will stick to it. No more building a little pile of tiny screws as I take apart a computer while hoping they don't roll away or I knock them over.
It's for home, but I'm thinking about getting another at work.
Every compiler vendor who has sold a mainstream language compiler/IDE using a "program database" or some other such approach has tanked. (Note that I mean program database as the primary means of storing the code -- a replacement of flat files, not an addition to them.) So far, it's not really been a technological lack, it's just that programmers don't like it.
I recall reading some papers written by the major language guys a decade ago, and one of the things they all wanted to see was per-function recompilation (instead of per-translation-unit), better program information (like "where is this function used?") and other things that would require a more database-like format. Still hasn't happened except in research environments. (Pity.)
One could, but one would be a lunatic.
(I'm too tired to write it all down now, but I'll just summarize by saying that XML is not a silver bullet.)
Wow. They have been working on Perl 6 for a long time.
My coder girlfriend gave me some of that as one of my birthday gifts. Apparently my caffeine tolerance is so high that it's merely like an additional sip of coffee after drinking 5 cups: just not enough to register.
Damn.
She doesn't drink nearly as much caffeinated beverages as I do, though. I'm going to have her try it and see what happens.
I work as sysadmin on an Air Force base. We have a commercial support contract with Sun that specifies they get replacement parts to us in 4 hours. The other day a hard drive died, and I had the amusement of writing in the support request, "I know where Sun's headquarters are; get me a new hard drive in 4 hours or I call in an airstrike."
(Then I thought some more about it and erased that sentence. Damn humorless paper-pushers. (So of course it took six hours for the drive to get to me.) Oh well.)
You teach by example, and do both. Andrew Koenig and Barbara Moo, two of the prime movers behind C++, wrote a book called Accelerated C++: Pratical Programming by Example , as a new approach to teaching C++.
It absolutely kicks ass. Somebody else on this page commented that you need to learn C before learning C++. Most C++ people disagree; this book proves them correct. It starts with
and the first lesson was, "the most important line in this program is the second one," i.e., the comment. How refreshing is that? It does not then follow up by diving into the guts of the IOstream library; they simply say, "when you want to send stuff to the screen, use this; when you want to get stuff from the keyboard, use this," and leave the details for later. Even though the IOstream library involves OOP, they don't shove the user's nose in it.The people I know who have started using this book, and the approach that they advocate, to teach beginning programmers, have all found their students not only picking up the language faster, but being less frustrated with programming in general (admit it, we've all been there), and having a better understanding of what's happening in their code.
(Pointers aren't even introduced until chapter 9 or 10, which means anything that visibly uses pointers isn't needed until then, either. Very nice.)
Kernighan (the 'g' is silent) is the K in K&R C. He wrote,
We would do well to remind students at every opportunity that "clever" may be a complement in back-room business deals, but it's usually spoken with heavy irony in programming.
In addition to explaining all that (and TAOCP is the only place I've ever seen it explained), Knuth goes on to give the translation: Rules of equating and restoring.
The C++ standard says nothing about ABIs. (Well, there are some layout rules when dealing with POD structs, but nothing about a C++ ABI.)
We're not meeting the C++ standard in two regards (at least I can't think of any more): first, we don't have export for templates. That will largely be a fallout of the precompiled header projects (two or three PCH branches have been in the repository for a long time now; both Apple and Red Hat have been contributing their implementations).
Second, we don't do two-stage name lookup for templates. Which most user don't need to worry about. That will come when the current 15-year-old parser has finished being rewritten (and there are branches doing that already as well).
Also, keep in mind that although the compiler C++ ABI is stable, the C++ library ABI is not. Declaring it stable at this point would be a massively stupid thing to do; there are far too many optimizations to be made still, and those involve changing the ABI. For example, there's a reworking of the memory allocator that currently exists on my whiteboard, and as soon as it gets finished off and checked in, the library ABI will be broken. Vendors already have methods in place for dealing with multiple versions of a library installed; this will be nothing new to them.
Hi. I'm one of the hundred-odd GCC maintainers.
Because the idea of backwards compatability never occured to any of us until we read your Insightful post. My God, what a concept! I'll go tell them at once!
Seriously, what makes you think the entire team doesn't already understand this point? Do you think such decisions are made lightly? Go read the archives; they agonized over this for months, and that was before the heavy debating started.
Here's the simple fact: there is a C++ ABI designed for compatability and interoperability. Here's another simple fact: there were bugs in our implementation of the ABI. The choice was to be backwards-compatable with previous GCC 3.1 and incompatable with other vendors implementing the same spec -- which would pretty much defeat the purpose of a common ABI. Or we could fix the bugs and break compatability in a couple of corner cases.
Of course, after all the details are worked out is when all of the geniuses with answers to all of life's problems decide to reveal The One True Solution on /. posts...
Especially since this fact was announced weeks ago. Amazing skillz of foresight ya got there.
Die-hard fans don't need to buy the movie, now or ever.
Die-hard fans didn't need a movie in the first place, because no director anywhere -- skilled as Peter Jackson or not -- could come up with a movie as good as what we've had in our heads since the first time we read Tolkien.
Your comments apply to the die-hard sheep, not the die-hard fans. And those are hardly limited to Tolkien.
ninety-nine little bugs in the code,
ninety-nine little bu-u-u-gs,
fix a bug,
compile again,
one hundred and one little bugs in the code!
The next verse went from 101 to 105, then from 105 to 113, then from 113 to 129, and so forth, adding a new power of two on each loop.