I wonder how much of that has to do with the ridiculous Makefiles (ok, Makefile.ins) that get generated if you use automake.
Nothing whatsoever. Those are created long before the user (not the developer) runs 'configure'.
As to the size... well, yeah, you need that in there if you're going to be portable, and safe, and not use any weird extensions for weird versions of make, and still support all the makefile targets that a mature project would require. (Packaging, cleaning, dependancies, relocatable installation trees, etc.)
If you don't need all that stuff, you can turn off large chunks of it.
Makefiles are often poorly written. In particular, people very often fail to use.include directives properly.
Make itself is badly underspecified. POSIX Make simply doesn't scale well enough to support a medium-sized or larger project; it doesn't standardize anything like dependancy tracking or including other makefile fragments.
As a result, every implementation of make grew its own features to handle the deficiencies. Including files, to take your example, can be done with every make program out there -- but the syntax, and the exact behavioral semantics, is subtly different across all the implementations. So it's very easy to get wrong.
(That's one of the reasons why I like automake. It handles a lot of that for me, generating a makefile.in which doesn't depend on GNU make or BSD make or whatever.)
"aid that, I do agree that a good autoconf configuration is very hard to acomplish, mainly when you doing it for the first time."
I don't know of any aspect of computer programming that's both non-trivial and easy to accomplish, when you're going it for the first time.
If autoconf is so problematic and PITA, why use it in the first place?
autoconf/make is more trouble than it's worth.
You know, I've never had that much trouble with it. I've never had more trouble than doing it by hand would have given me.
I've certainly never found a different system that saves me more time while maintaining the degree of portability required for most of our projects. I'm sure if we decided that "all the world's a PC," or even "all the world runs Linux," we could do it by hand, but that's not good enough.
Portable makefiles and small portability test programs is the right way to do it.
I couldn't agree more. That's why I use a generator of insanely portable makefiles (it's a tool called automake), and a tool which creates and runs small portability test programs (it's called autoconf).
Re:automake is not required to use ./configure
on
Debugging Configure
·
· Score: 1
It's not so much the minor incompatabilities, in my experience, it's the overeagerness of developers to keep bumping the "minimum required version" needlessly, just to use the latest.
Autoconf did a huge leap, with many changes, and some projects still use the last of the old versions (2.13). Automake had a series of broken minor versions, so there's a jump from 1.4 to 1.7 or so.
Both automake and autoconf can have multiple versions sit side-by-side, so that's what some distros do; and Debian, at least, has a wrapper script for each tool which tries to figure out the proper version to use by looking at the contents of the input files, and I can't remember whether it falls back on the latest or the oldest if there are no hints in the file. I think there's two versions of autoconf and three versions of automake installed, and it all just works. You might could do that, maybe; the wrapper detecting scripts are (presumably?) out there somethere.
The "code for checking" is all just a bunch of macros. Believe me, the slowdown you see isn't the shell reading a bunch of lines of text.
Some points that might speed things up:
Some shells suck. The generated configure is designed to not require any modern shell features (in case you run it on some ancient piece of crap), so you can use whatever stripped-down streamlined implementation of Bourne shell you want. (Assuming the developers of whatever package you're installing haven't used such features themselves, and most don't, for the same reasons that autoconf recommends.)
Some shells really suck. Under Solaris and AIX, for example,/bin/sh is such a flaming piece of shit that people running non-trivial configures are advised to run configure with a different shell.
If you're getting the same results for commonly-used tests, strip them out of the generated cache, keep the cache around, and when you go to run a new package, preload the cache. (Can be tricky, but is usually safe. Just cache the safe stuff like, "checking if CPU is on fire... no".
On recent Linux systems, a big slowdown is the part at the very end, when files like Makefile and config.h are being created. These are basically huge sed operations. Recent versions of sed and glibc have really taken a performance hit in this area. (Depends on your distro. Some sed's are compiled with their own regex engine, some use glibc's. There're more details, but I'm pressed for time.) You might try timing the last part (running config.status over and over to get an average time), then putting a different sed in your PATH and trying again. I found old versions of "ssed" to really kick ass.
And you're saying that automake is NOT an
unmitigated disaster?
Huh? When did this switch from autoconf to automake? Okay, sure, I'll play. I think automake is a fine tool.
In my view any project that needs to resort
to automake in order to configure the build
environment
Your view is wrong, since that's not what automake is for. That's autoconf's job.
It has failed
to deliver a portable Makefile,
Here you're clearly talking out of your ass. Go look at a generated Makefile.in. It's whole purpose in life is to be more portable than any hand-written makefile could ever be. Go ahead, try to implement the same complicated, real-world-necessary rule patterns yourself, without resorting to a nonportable feature of GNU make, or BSD make, or Sun make, or...
The point is to save typing during the input (Makefile.am) and yet keep the output (Makefile.in/Makefile) utterly portable. And it succeeds admirably. What, you'd rather force everyone to maintain hundreds of lines of makefile by hand?
and failed to
deliver portable application source code,
What the fuck does that have to do with the makefile? Or the build system? This is a red herring, and a specious argument.
and tried to work around that failure after
the fact by patching it with automake.
...a tool which, in fact, does not actually patch any files. Brilliant argument there, buddy. Perhaps you should pay attention to which tool does what.
Feh. Go back to your hand-written tedious makefiles. I'll stick with tiny free-form automake files. And add you to my/. killfile.
When one of my friends and I were both getting our clearances, we joked ahead of time about the final step, the one-on-one interview with a Very Serious Agent[tm]. He suggested:
"One of my fondest childhood memories was laying in a crib, and a man with a heavy Russian accent leaning over me and saying, 'Excellent, Boris, now his mind will be putty in our hands.'"
or
Agent: "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?" [*]
Hapless Geek: "Uh, not sure, lemme check with the {Boy Scouts, IEEE, marching band director} on that one."
Both of us had the same experience: we each kinda had it in the back of our heads right up until the agent asked some very heavy question which let you know that it was not a game at all, and then the joke went right out the window. I at least told the agent some of the jokes after the interview was over.:-)
[*] Actual question, just like the 60's spy movies. No kidding. Word for word. It was not a forgettable moment, let me assure you.
Rather than attempting to include support for every architecture via autoconf, [...] Rather than doing a poor job of supporting every platform, it makes much more sense to support one platform directly,
That's exactly how autoconf doesn't work. "Including support for every architecture" is how previous build systems worked, like xmake. Those were an unmitigated disaster.
Automake's goal is to allow the build system to adapt itself to whatever system happens to be available. It does not look at the OS and say, hey, I'm on Solaris, bring out these hardcoded settings. Instead it performs tests for each feature of interest -- where is the compiler? where are the SSL libraries? what's the exact function signature for this not-quite-standard-C subroutine? If your system has been customized from the factory default, so to speak, then hardcoded answers will be wrong, no matter how dilligently those porting people were in originally deriving them.
The idea is to have configure discover whatever the correct answers are, and set variables appropriately so that you don't have to care about the differences -- you can write the code once, as you say, and let the automatics do the necessary adjustments, rather than other people. Assume you're running on a POSIX system, for example, and let configure #define things as necessary to make up for the non-POSIX systems.
The webpage missed a major resource
on
Debugging Configure
·
· Score: 4, Informative
The GNU Autotools have their own published book, the electronic edition of which is
online. This doesn't seem to be listed in the resources at the end of the article.
This is why you should read your post before clicking submit, boys and girls.
All five are regions of gravitational equilibrium and stability
Sorry, I didn't mean to imply they're stable enough to build stuff there. The straight-line points (L1, L2, and L3) are stable only compared to the points in other random space around them.
Stuff placed there eventually falls away.
The orbital points (L4 and L5) are truly stable, in the sense of being self-correcting. Stuff placed there has to work to get out.
A space station at the Lagrange point would need some energy to stay in position anyway - it would invariably drift over time if not corrected due to the solar wind and inaccuracies in the initial positioning.
Not nearly as much as you think; possibly none at all. That's the whole reason to put one in the Lagrange points, well, half the reason anyway.
You know those "gravity/mass" diagrams that start with a flat Cartesian grid, and whenever a body is added, it sinks down like a well, or a rock weighing down a bedsheet? More massive bodies create larger wells, and so forth? Imagine the Earth (large well) and the Moon (small well). Now imagine 5 tiny dimples, moving in the same stable orbits along with the Earth and Moon.
Anything humans can build anytime soon is going to mass very little than the bodies involved in the system (Earth and Moon), and will fit comfortably within those dimples. The dimples are shallow; it doesn't mean we can just sort of get close and then suddenly the spaceport will fall in and get jerked into place. But "stationkeeping" will require much less work (fuel) than if we had been in some other random orbit point, out there on top of the bedsheet.
The other half of the reason behind choosing a Lagrange point is that they're connected by "superhighways" where the energy required to travel between them is less than normal... I'm explaining this poorly, I know... imagine little grooves carved between the dimples; a small enough marble can just roll between the various dimples with a very small push and not much steering.
It's not just the Earth/Moon points that pick up stuff. Any time you have a body in a stable orbit around another body, the five Lagrange points are created. Presumably we could put an even bigger station at, say, the L5 point in the Earth/Sol set.
All five are regions of gravitational equilibrium and stability, it's just that L4 and L5 are especially likely to capture things, since they're in the same orbit as one of the bodies, which is usually "shedding".
I've heard that one of the early space missions had problems with one of its windows "fogging" with micro-micro-metorite impacts; they'd accidentally flown through one of the Earth/Moon points, where a lot of dust had collected.
Another thing while I'm all steamed up, isn't the LaGrange point between the earth and moon L1?
Yes. And while all the Lagrange points are stable, the L4 and L5 points are even more stable (more massive objects can sit in them and catch the ride, as it were).
I'm not sure why they talk about L1. All the predictions I've ever read, over the last several years, have always placed the hypothetical space station at L5. (Why L5 over L4? I'd be guessing there, sorry.)
but why has nobody mentioned finding the perpetrators?/em>
My opinion: for the same reason that officers of the peace make only vague handwavey-type sounds when asked if they have leads on the suspect of a crime.
If they say they have no leads, then they look like idiots.
If they say they have leads,
and they're bluffing, then they look like incompetent liars and fradulent idiots.
and they really do have leads, they won't possibly actually mention them because that would set themselves up for a slander/libel/defamation-of-character lawsuit if they can't make it stick.
and they really do have irrefutable proof, then they're not going to tip their hand before law enforcement breaks down the doors of the goatfuckers.
So why brag about leads on/.? They have nothing to gain and everything to lose.
Why wouldn't he make an extended edition? Splitting the EEs across two DVDs kinda handles the intermission part. I mean, ya gotta stand up long enough to change dics, and while you're up you might as well take a bathroom break, and maybe eat a meal, and heck just watch the second half tomorrow...
If Jackson says it's the best, I'm willing to take his word for it. (Until I see it for myself, and even then I'll probably agree with him, because I have done so in the past.)
I've been watching the making-of interviews and listening to the commentary tracks on the Extended Two Towers DVD With Extra Ass-Kicking And Shiny Bits. Jackson and Walsh explain their reasoning behind the "controversial" decisions (Elves at Helm's Deep, no Shelob, Faramir's initially a jerk, side trip to Osgiliath, etc). The decisions are actually all chained together. And now that I've heard the screenwriter's/director's side of the story, instead of just/. ravings, I have to admit that they probably made the right decisions.
(Okay, maybe not about the Elves showing up. I'm still on deciding that one. The lack of Shelob (leading to the trip to Osgiliath) makes more sense now.)
There's a great comment by Bernard Hill, who played Theoden. (Background: Many of the desired accents changed during the course of filming, and of course there's script rewrites and background noise and whatnot, so almost every actor had to go into a soundbooth at the end and record some overdubs of his/her previous lines.) Anyhow, Hill was recording the lines where the Elves walk into the fortress and he comes running down the stairs.
As a joke on Peter Jackson, instead of "How is this possible?", he recorded:
"Why? Because Microsoft has declared that thir next operating system will only run on Trusted Computing hardware and it is flat-out IMPOSSIBLE to sell hardware if it can't run Windows."
This is stupid. If no motherboards adopted trusting computing, it'd be fucking hard to sell Windows.
If we had some fish, we could have fish and chips, if we had some chips.
We all know the inscription on the Doors of Durin: " blah blah blah, Lord of Moria, blah blah blah". And yes, it really does say "Moria," that's not just editorializing by Gandalf to entertain the Fellowship. The rest of the inscription says that the Doors were made by a famous Dwarf, and the inscription carved by a famous Elf, because the races got along okay at the time.
Except... moria is an insulting name. It means "Abyss" or (literally) "Black Pit." Nobody would have called the Kingdom of Khazad-Dum an abyss when it was at the height of its splendor. The name "Moria" was only earned long years later, after they woke the Balrog and abandoned the kingdom.
In any case, the Dwarves certainly wouldn't have let the Elves carve such an insulting name on the west entrance, and the Elves wouldn't have wanted to.
Some of his published letters describe his feelings on the possibility of a movie. He didn't like the idea for the same reason that many of the die-hard fans don't -- it's impossible to translate everything onto the screen.
But he wasn't dead-set against the idea. He gave his reluctant permission. (Then got really disgusted at the screenplays.)
I'm looking at a soup of = and & and I see no GET. Maybe it's buried in there slmewhere, but I'm not going to hunt through it only to have the "editors" rvamp things a week later and break it.
Poor decisions on their part are not my responsibility to fix or work around. If they want me to spread the word, they can damn well help me.
The idea behind Flash Click-to-View is a really great one, but the installer is broken, there's no uninstaller, the assumptions made by the author about how one browses the web are just stupid (only works as root? please), and the worst part is that he's not fixing any of this. He's not even talking to the users asking for help.
So, it's much like most of the other mozdev extensions I've tried.:-) It compiles/parses/looks pretty! Ship it and ignore it!
is that the default comment view (i.e., when you don't have an account) is non-threaded, oldest first. Which is just stupid. People visiting are treated to pages of whatever the current first-post troll is these days.
Switch the default to threaded, highest scores first, and then if a visitor wants a more chaotic view, they can deliberately ask for it.
Slashdot Mirror
Nothing whatsoever. Those are created long before the user (not the developer) runs 'configure'.
As to the size... well, yeah, you need that in there if you're going to be portable, and safe, and not use any weird extensions for weird versions of make, and still support all the makefile targets that a mature project would require. (Packaging, cleaning, dependancies, relocatable installation trees, etc.)
If you don't need all that stuff, you can turn off large chunks of it.
Make itself is badly underspecified. POSIX Make simply doesn't scale well enough to support a medium-sized or larger project; it doesn't standardize anything like dependancy tracking or including other makefile fragments.
As a result, every implementation of make grew its own features to handle the deficiencies. Including files, to take your example, can be done with every make program out there -- but the syntax, and the exact behavioral semantics, is subtly different across all the implementations. So it's very easy to get wrong.
(That's one of the reasons why I like automake. It handles a lot of that for me, generating a makefile.in which doesn't depend on GNU make or BSD make or whatever.)
I don't know of any aspect of computer programming that's both non-trivial and easy to accomplish, when you're going it for the first time.
You know, I've never had that much trouble with it. I've never had more trouble than doing it by hand would have given me.
I've certainly never found a different system that saves me more time while maintaining the degree of portability required for most of our projects. I'm sure if we decided that "all the world's a PC," or even "all the world runs Linux," we could do it by hand, but that's not good enough.
I couldn't agree more. That's why I use a generator of insanely portable makefiles (it's a tool called automake), and a tool which creates and runs small portability test programs (it's called autoconf).
It's not so much the minor incompatabilities, in my experience, it's the overeagerness of developers to keep bumping the "minimum required version" needlessly, just to use the latest.
Autoconf did a huge leap, with many changes, and some projects still use the last of the old versions (2.13). Automake had a series of broken minor versions, so there's a jump from 1.4 to 1.7 or so.
Both automake and autoconf can have multiple versions sit side-by-side, so that's what some distros do; and Debian, at least, has a wrapper script for each tool which tries to figure out the proper version to use by looking at the contents of the input files, and I can't remember whether it falls back on the latest or the oldest if there are no hints in the file. I think there's two versions of autoconf and three versions of automake installed, and it all just works. You might could do that, maybe; the wrapper detecting scripts are (presumably?) out there somethere.
The "code for checking" is all just a bunch of macros. Believe me, the slowdown you see isn't the shell reading a bunch of lines of text.
Some points that might speed things up:
Huh? When did this switch from autoconf to automake? Okay, sure, I'll play. I think automake is a fine tool.
Your view is wrong, since that's not what automake is for. That's autoconf's job.
Here you're clearly talking out of your ass. Go look at a generated Makefile.in. It's whole purpose in life is to be more portable than any hand-written makefile could ever be. Go ahead, try to implement the same complicated, real-world-necessary rule patterns yourself, without resorting to a nonportable feature of GNU make, or BSD make, or Sun make, or...
The point is to save typing during the input (Makefile.am) and yet keep the output (Makefile.in/Makefile) utterly portable. And it succeeds admirably. What, you'd rather force everyone to maintain hundreds of lines of makefile by hand?
What the fuck does that have to do with the makefile? Or the build system? This is a red herring, and a specious argument.
...a tool which, in fact, does not actually patch any files. Brilliant argument there, buddy. Perhaps you should pay attention to which tool does what.
Feh. Go back to your hand-written tedious makefiles. I'll stick with tiny free-form automake files. And add you to my /. killfile.
When one of my friends and I were both getting our clearances, we joked ahead of time about the final step, the one-on-one interview with a Very Serious Agent[tm]. He suggested:
"One of my fondest childhood memories was laying in a crib, and a man with a heavy Russian accent leaning over me and saying, 'Excellent, Boris, now his mind will be putty in our hands.'"
or
Agent: "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?" [*]
Hapless Geek: "Uh, not sure, lemme check with the {Boy Scouts, IEEE, marching band director} on that one."
Both of us had the same experience: we each kinda had it in the back of our heads right up until the agent asked some very heavy question which let you know that it was not a game at all, and then the joke went right out the window. I at least told the agent some of the jokes after the interview was over. :-)
[*] Actual question, just like the 60's spy movies. No kidding. Word for word. It was not a forgettable moment, let me assure you.
That's exactly how autoconf doesn't work. "Including support for every architecture" is how previous build systems worked, like xmake. Those were an unmitigated disaster.
Automake's goal is to allow the build system to adapt itself to whatever system happens to be available. It does not look at the OS and say, hey, I'm on Solaris, bring out these hardcoded settings. Instead it performs tests for each feature of interest -- where is the compiler? where are the SSL libraries? what's the exact function signature for this not-quite-standard-C subroutine? If your system has been customized from the factory default, so to speak, then hardcoded answers will be wrong, no matter how dilligently those porting people were in originally deriving them.
The idea is to have configure discover whatever the correct answers are, and set variables appropriately so that you don't have to care about the differences -- you can write the code once, as you say, and let the automatics do the necessary adjustments, rather than other people. Assume you're running on a POSIX system, for example, and let configure #define things as necessary to make up for the non-POSIX systems.
The GNU Autotools have their own published book, the electronic edition of which is online. This doesn't seem to be listed in the resources at the end of the article.
This story was actually my first encounter with Lagrange points. Boy, I was one confused reader.
This is why you should read your post before clicking submit, boys and girls.
Sorry, I didn't mean to imply they're stable enough to build stuff there. The straight-line points (L1, L2, and L3) are stable only compared to the points in other random space around them. Stuff placed there eventually falls away.
The orbital points (L4 and L5) are truly stable, in the sense of being self-correcting. Stuff placed there has to work to get out.
Right. I think the predictions have always used L5 because it's conceivably easier to transport crap from Earth to L5 than it is from Earth to L4.
Not nearly as much as you think; possibly none at all. That's the whole reason to put one in the Lagrange points, well, half the reason anyway.
You know those "gravity/mass" diagrams that start with a flat Cartesian grid, and whenever a body is added, it sinks down like a well, or a rock weighing down a bedsheet? More massive bodies create larger wells, and so forth? Imagine the Earth (large well) and the Moon (small well). Now imagine 5 tiny dimples, moving in the same stable orbits along with the Earth and Moon.
Anything humans can build anytime soon is going to mass very little than the bodies involved in the system (Earth and Moon), and will fit comfortably within those dimples. The dimples are shallow; it doesn't mean we can just sort of get close and then suddenly the spaceport will fall in and get jerked into place. But "stationkeeping" will require much less work (fuel) than if we had been in some other random orbit point, out there on top of the bedsheet.
The other half of the reason behind choosing a Lagrange point is that they're connected by "superhighways" where the energy required to travel between them is less than normal... I'm explaining this poorly, I know... imagine little grooves carved between the dimples; a small enough marble can just roll between the various dimples with a very small push and not much steering.
It's not just the Earth/Moon points that pick up stuff. Any time you have a body in a stable orbit around another body, the five Lagrange points are created. Presumably we could put an even bigger station at, say, the L5 point in the Earth/Sol set.
All five are regions of gravitational equilibrium and stability, it's just that L4 and L5 are especially likely to capture things, since they're in the same orbit as one of the bodies, which is usually "shedding".
I've heard that one of the early space missions had problems with one of its windows "fogging" with micro-micro-metorite impacts; they'd accidentally flown through one of the Earth/Moon points, where a lot of dust had collected.
Yes. And while all the Lagrange points are stable, the L4 and L5 points are even more stable (more massive objects can sit in them and catch the ride, as it were).
I'm not sure why they talk about L1. All the predictions I've ever read, over the last several years, have always placed the hypothetical space station at L5. (Why L5 over L4? I'd be guessing there, sorry.)
My opinion: for the same reason that officers of the peace make only vague handwavey-type sounds when asked if they have leads on the suspect of a crime.
So why brag about leads on /.? They have nothing to gain and everything to lose.
Why wouldn't he make an extended edition? Splitting the EEs across two DVDs kinda handles the intermission part. I mean, ya gotta stand up long enough to change dics, and while you're up you might as well take a bathroom break, and maybe eat a meal, and heck just watch the second half tomorrow...
If Jackson says it's the best, I'm willing to take his word for it. (Until I see it for myself, and even then I'll probably agree with him, because I have done so in the past.)
I've been watching the making-of interviews and listening to the commentary tracks on the Extended Two Towers DVD With Extra Ass-Kicking And Shiny Bits. Jackson and Walsh explain their reasoning behind the "controversial" decisions (Elves at Helm's Deep, no Shelob, Faramir's initially a jerk, side trip to Osgiliath, etc). The decisions are actually all chained together. And now that I've heard the screenwriter's/director's side of the story, instead of just /. ravings, I have to admit that they probably made the right decisions.
(Okay, maybe not about the Elves showing up. I'm still on deciding that one. The lack of Shelob (leading to the trip to Osgiliath) makes more sense now.)
There's a great comment by Bernard Hill, who played Theoden. (Background: Many of the desired accents changed during the course of filming, and of course there's script rewrites and background noise and whatnot, so almost every actor had to go into a soundbooth at the end and record some overdubs of his/her previous lines.) Anyhow, Hill was recording the lines where the Elves walk into the fortress and he comes running down the stairs. As a joke on Peter Jackson, instead of "How is this possible?", he recorded:
"Who the fucking hell let you lot in the gate?"
See if your cellphone is now on the PalantirNet[tm] service plan. If it is, try not to touch it if the LCD screen shows a glowing eye, okay?
If we had some fish, we could have fish and chips, if we had some chips.
...try time-travelling Elves.
We all know the inscription on the Doors of Durin: " blah blah blah, Lord of Moria, blah blah blah". And yes, it really does say "Moria," that's not just editorializing by Gandalf to entertain the Fellowship. The rest of the inscription says that the Doors were made by a famous Dwarf, and the inscription carved by a famous Elf, because the races got along okay at the time.
Except... moria is an insulting name. It means "Abyss" or (literally) "Black Pit." Nobody would have called the Kingdom of Khazad-Dum an abyss when it was at the height of its splendor. The name "Moria" was only earned long years later, after they woke the Balrog and abandoned the kingdom.
In any case, the Dwarves certainly wouldn't have let the Elves carve such an insulting name on the west entrance, and the Elves wouldn't have wanted to.
Oops. :-)
Some of his published letters describe his feelings on the possibility of a movie. He didn't like the idea for the same reason that many of the die-hard fans don't -- it's impossible to translate everything onto the screen.
But he wasn't dead-set against the idea. He gave his reluctant permission. (Then got really disgusted at the screenplays.)
I'm looking at a soup of = and & and I see no GET. Maybe it's buried in there slmewhere, but I'm not going to hunt through it only to have the "editors" rvamp things a week later and break it.
Poor decisions on their part are not my responsibility to fix or work around. If they want me to spread the word, they can damn well help me.
The idea behind Flash Click-to-View is a really great one, but the installer is broken, there's no uninstaller, the assumptions made by the author about how one browses the web are just stupid (only works as root? please), and the worst part is that he's not fixing any of this. He's not even talking to the users asking for help.
So, it's much like most of the other mozdev extensions I've tried. :-) It compiles/parses/looks pretty! Ship it and ignore it!
is that the default comment view (i.e., when you don't have an account) is non-threaded, oldest first. Which is just stupid. People visiting are treated to pages of whatever the current first-post troll is these days.
Switch the default to threaded, highest scores first, and then if a visitor wants a more chaotic view, they can deliberately ask for it.