For the majority of people, Pulseaudio has what you need and is also portable to Windows. Many (most?) distros are already moving or have completed their move to Pulseaudio. As far as I'm concerned, this issue is addressed, save only for migration time for slow adopters.
That's always the problem, isn't it? Slow adopters, I mean. Your average Linux distro is full of old code that hasn't been updated to the latest standards. There's still code on my system that uses the OSS compatibility, for instance... I forget, did the Flash plugin ever move on to ALSA? I assume they haven't even thought about moving to Pulseaudio yet... (JACK is still new to me, and I'd never heard of Pulseaudio before... Good to know things are moving forward with regard to better audio servers... esd never seemed to get the job done as an all-purpose audio server...)
To that end, there's little or no centralized configuration: everything in the system is controlled through a welter of files, and there's no guarantee that the syntax of any one configuration file will apply to any other.
Obviously the solution is to rewrite every program in the OS to use a standard configuration file format. Instead of, you know, writing a man page that explains how the configuration file works.
My issue with this is that, when working from a shell (and particularly scripting), the fact that every program has its own configuration file format, and that hardly any pair of formats shares even the most basic assumptions about format, value separation, etc. makes the whole process needlessly difficult.
I think some reform may be in order for some formats - but I don't think they need to be unified. What might be helpful is a unified interface to all that data - if every distinct format came with an interface library to make it easier to edit that data - for code that doesn't know or care how, precisely, that data is formatted... That would be plenty.
Bottom line: the author doesn't like Linux, doesn't bother to understand it, and wishes it were more like a proprietary OS controlled by a single vendor.
From your perspective, that may be the case. But when you're developing (closed-source) applications for Linux, these are real problems, real obstacles... Strong leadership and attention to these issues - yes, like you'd find in a proprietary OS - is very helpful in that regard.
If you don't feel sympathy for people in that position - I can relate to that, at least. Linux, to me, isn't about commercialization. But, you know, I can relate to the other viewpoint, too - being one of those guys who occasionally has to deal with these kinds of issues.:)
To answer the subject-line question - "if it needs fixing, then why isn't it fixed?" - because wanting it fixed doesn't fix it. Somebody needs to do the work. And when the problem is a lack of a stable standard, the solution can only be provided by someone with sufficient influence to impose such a standard.
So, you de-bunk a lot of the coarser points of what the dude says, but there are finer points to these issues that I think deserve attention...
1: Package Management: Remember it's not just the packaging format... If that were all, then it'd be (almost) adequate to just provide a tarfile. But what people want from a package is proper support for dependencies, as well as a clean removal option. Dependencies are the problem, since different distros (even based on the same package format) have different libraries and may not be entirely compatible.
2: Files under/etc can be backed up and restored... Well, the registry can be, too. Powershell gives you a shell scripting interface to it. I wouldn't say the registry is a perfect system but it does have its merits. What's nice about putting this stuff on the filesystem is it's relatively easy to explore - but this is mainly a matter of naming and style. In the registry a lot of things are referred to by GUID - which has the advantage of avoiding name clashes (whether from different apps or different versions of the same app) - but the disadvantage of being totally unreadable. QX, the registry was designed for machines, while/etc is more of a compromise between machines and users. What would be useful IMO is a compromise that still provides more of the advantages of GUID use and compact binary representation, without losing the user-accessibility at the shell level.
I think the name clashing issue is a real problem. In a filesystem, one expects everything to have a name (even if there is no sensible choice for a "name" for the thing) - and every name has to be unique, and the uniqueness of any given thing is purely a function of that name. This is a strategy that doesn't scale well. If two groups decide to give different things the same name, there's no sorting that out, it's simply a conflict. For now this works out reasonably well, not too many name clashes in programs, libraries, or configuration files... But the strength of all the GUID use in Windows is that these identifiers are smaller than most filenames but do a better job of distinguishing entities.
3: Kernel ABI I'd add that the application ABI isn't entirely stable, either... Implementation changes in libstdc++ (within the same major version number, even!) mean that if you build something in one version of g++, and build something else in another version of g++, you can't rely on being able to dynamically link the two together. The result could be dangerous library symbol imposition resulting in, for instance, erroneous allocation handling or a crash. As with many of these issues it isn't a "Linux" (kernel) issue but something developers have to deal with when programming for Linux-based systems. I've always found the handling of symbols between dynamically-linked modules a bit problematic, really...
4: File Versioning To me the issue here isn't the presence or absence of the feature (it's present in some form, I guess) - the more important issue is that, like xattr's, these aren't taken as a default assumption by most of the programs people regularly use. The features are there but mostly unutilized. This will take a lot of time to change.
6: I'm not clear on what features the guy wants the kernel (or some set of standard libraries) to provide to all GUIs. Object brokership? (I would like that, I think...) Something else?
7: His point was more about what happens after X crashes, I think - saying that what can be salvaged of your working session should be. But it is. The X server crashes, the programs realize they don't have a connection to a display server any more, and they shut down. Unless the apps themselves are crashed, they still have the ability to do a clean shutdown, save state, etc...
fuck that! If I ever see programs like cp become bloated with X library calls because some news reporter needs to see a GUI progress bar, I'm going to be very angry.
OK, but consider this...
Imagine that it's the shell that contains all that complicated stuff for managing a UI, handling progress bars, etc. - and programs running in the shell have a relatively lightweight way to report status updates to the shell.
cp remains relatively unbloated
non-interactive shell sessions (i.e. scripts) are unaffected
GUI code is centralized, which means that for a certain class of problems, all apps have a simple solution
Since the GUI code is centralized, it is consistent between apps that take advantage of it
Dude gets his progress bar on "cp" (not an unreasonable request, IMO...)
Basically, I argue that "cp" shouldn't be an X program, but rather the shell should provide it with a simple way to display a progress report, which the shell would implement properly for different display types.
Obviously for a solution like this there's some forethought required, to choose the desirable trade-off point between functionality and simplicity... And a feature like this can't possibly serve every scenario perfectly. But if we step away from the idea of what a "terminal" traditionally has been, and think about what kind of data channels we want, what kind of relationship we want, between the program we run, the shell we run it in, and the display we use to interact with it... I think it's worth revisiting that. Is the current solution, where a program's output is expected to serve as both user display and data output for further processing, really sensible? It seems to me that chaining the two together limits both: the user display is limited by the need to have it be processable, and kept inflexible for reasons of compatibility... And for processing, the data format can't be made more efficient because that would interfere with its double-duty as raw-form UI.
Fuck. We have all the problems of Case 2, and more. We just made a person that is, by definition, part of the world's smallest and loneliest minority. He or she will never be able to live a remotely normal or fulfilling life.
That's assuming quite a lot, isn't it? Lots of people are born into unfortunate circumstances - not all of them wind up miserable and dejected for their entire life.
I think this whole situation really illuminates the valuable services provided by the Mad Scientist community. Others may laugh, or say that they're toying with forces man was not meant to comprehend... But they perform the science others don't dare attempt. And the price they pay, they earn the hatred of all those who didn't want to see the experiments done in the first place... Maybe they wind up buried under tons of lava after a well-dressed gentleman pays a visit to their secret volcano lair... It's a hard life, but they endure it, out of love of the game and their firm belief in the importance of science...
Yeah, but this requires just 3 lightbulbs worth of power (or whatever) - Moisture Vaporators need Power Converters, and then there's the trip to the Toshi station. No comparison, really.
And more importantly, Moisture Vaporators only speak Bocce - so unless you know the difference between "raffa" and "volo" you're out of luck.
Rather than focus on taking the cell phones away, we should ask ourselves: what good is a phone call if you can't talk?
...Well, I guess the answer to that is that you could still text somebody, or use a TDD device or a modem, maybe fax something, or play songs on the touch tones like in Short Circuit 2, etc...
Oh yeah, and rigging it so prisoners can't speak might be slightly evil. We should examine the implications there before we do anything...
First, I can put together an AMD box equivalent to an Intel for about $200 bucks cheaper. That money goes into my Video Card and I wind up with a better overall System.
I just bought a new computer, looking at quad-core configurations from either Intel or AMD - and, granted, I'm not so in-touch with computer hardware as I used to be - but my impression from the reviews I'd seen, etc. was that AMD was slightly slower per clock-cycle than Intel, and that the range of available clock speeds didn't go as high, either. The one advantage AMD had was a better memory architecture... Which, given the fact that this is a quad-core system, is very important if you don't want the problem to be dominated by a bunch of cache misses - but still my impression was that the Intel offerings were stronger at the current time...
Main Entry: 2fail Function: noun Date: 13th century 1 : failure --usually used in the phrase without fail 2 : a failure (as by a security dealer) to deliver or receive securities within a prescribed period after purchase or sale
I very rarely (almost never) buy used games in a game store, because honestly I just don't think they offer a very good price on them. It'll be like new copy: $60, used copy: $55. Or if it's an older game it might be new copy: $30, used copy $25.
Now from a practical standpoint I don't care at all whether it's a new or used copy. There hasn't been a significant difference in quality in my experience. Plus I own a smallish house, I really can't take more accumulation of "stuff" - so in many cases I don't even keep things like the DVD case or manual. But if the price difference is so minor, it becomes a matter of principle: I don't want to pay new game prices for used games. The previous owner of the game got something out of the deal, the game store gets something out of the deal, I want something out of the deal, too. Like a real non-trivial savings.
Let's just take a moment to appreciate that sentence. In how many circumstances would a sentence like this be useful? How frequently can you imagine someone needing this point cleared up? It seems a delightful absurdity, and the fact that it developed out of the natural course of this discussion is highly enjoyable.
I can see where you are coming from, but an issue with Trademark is that it has to be exact. Using the name XEvil, and adding a surname to it sounds like, at LEAST, the original creator was endorsing your work or had some level of involvement. IceWeasel is not Firefox, and it is more than the opposite of the name.
My point is not about trademark or copyright, it is about respect.
Mutant Strain truly was a version of XEvil. I changed some things and added some things and made my own fork but it was the same game. The issue there was that I wasn't courteous in how I managed and promoted my fork. What I did with the game (apart from some mistakes I made in earlier versions of the fork, like remove the original author's credit entirely) was in line with the game's original GPL license, but it wasn't nice.
Likewise IceWeasel: as I said, I never really thought the name was disrespectful, but I can see how it could be taken that way. I don't think that name necessarily needs to be changed - but if this perception that it's a derisive or spiteful name choice is a common one then something should be done to address that: after all, free software depends on cooperation. Cooperation isn't just a matter of slapping a free software license on a program, it's about people showing each other courtesy and respect in how they deal with each other.
iceweasel was kind of a dick move from developers that didn't want to live up to the same expectations as everybody else.
I'm not certain why you think it's a "dick move" to do something that you're allowed to do. But I AM certain that they are living up EXACTLY to the same expectations as everyone else.
Oh! I can field this one... As someone who once made a fairly shitty, uncourteous move myself...
See, back in the late 90s I made a fork of the game XEvil. XEvil v1 was GPL'ed, while XEvil v2 was not. I forked a late version of v1 and called it "XEvil Mutant Strain" - added some characters and weapons and stuff, put my name on it, etc. It even wound up on a CD release of Linux games.
So why was this a shitty thing to do? Basically, during all this, I wasn't thinking in terms of how to be courteous to the original author of the software. In the case of Mutant Strain it was like "I'm gonna fork this 'cause I don't approve of your new license" - followed by a lot of shoddy work, and promotion of said shoddy work, using the name XEvil and without being courteous or thankful for the original code I was working from. I didn't do enough to distinguish my project as a fork and I didn't do enough to recognize the original author.
So I can appreciate the perspective from which someone says it was a shitty move to call the fork IceWeasel. I never really thought of it like that before - mostly I just thought the name choice was kind of funnny. But the fact that the name choice is kind of a parody (especially given all the name changes Firefox was subject to early on) is kind of ungrateful in a way - almost like the people who chose the name wanted to express spite toward the Firefox folks for creating the condition in which they couldn't change the source to fit their distribution and still call it Firefox. I think a more appropriate attitude is continuing thanks for making Firefox source free in the first place, even if there are uncomfortable limitations.
Slashdot Mirror
For the majority of people, Pulseaudio has what you need and is also portable to Windows. Many (most?) distros are already moving or have completed their move to Pulseaudio. As far as I'm concerned, this issue is addressed, save only for migration time for slow adopters.
That's always the problem, isn't it? Slow adopters, I mean. Your average Linux distro is full of old code that hasn't been updated to the latest standards. There's still code on my system that uses the OSS compatibility, for instance... I forget, did the Flash plugin ever move on to ALSA? I assume they haven't even thought about moving to Pulseaudio yet... (JACK is still new to me, and I'd never heard of Pulseaudio before... Good to know things are moving forward with regard to better audio servers... esd never seemed to get the job done as an all-purpose audio server...)
Obviously the solution is to rewrite every program in the OS to use a standard configuration file format. Instead of, you know, writing a man page that explains how the configuration file works.
My issue with this is that, when working from a shell (and particularly scripting), the fact that every program has its own configuration file format, and that hardly any pair of formats shares even the most basic assumptions about format, value separation, etc. makes the whole process needlessly difficult.
I think some reform may be in order for some formats - but I don't think they need to be unified. What might be helpful is a unified interface to all that data - if every distinct format came with an interface library to make it easier to edit that data - for code that doesn't know or care how, precisely, that data is formatted... That would be plenty.
Bottom line: the author doesn't like Linux, doesn't bother to understand it, and wishes it were more like a proprietary OS controlled by a single vendor.
From your perspective, that may be the case. But when you're developing (closed-source) applications for Linux, these are real problems, real obstacles... Strong leadership and attention to these issues - yes, like you'd find in a proprietary OS - is very helpful in that regard.
If you don't feel sympathy for people in that position - I can relate to that, at least. Linux, to me, isn't about commercialization. But, you know, I can relate to the other viewpoint, too - being one of those guys who occasionally has to deal with these kinds of issues. :)
To answer the subject-line question - "if it needs fixing, then why isn't it fixed?" - because wanting it fixed doesn't fix it. Somebody needs to do the work. And when the problem is a lack of a stable standard, the solution can only be provided by someone with sufficient influence to impose such a standard.
So, you de-bunk a lot of the coarser points of what the dude says, but there are finer points to these issues that I think deserve attention...
1: Package Management: Remember it's not just the packaging format... If that were all, then it'd be (almost) adequate to just provide a tarfile. But what people want from a package is proper support for dependencies, as well as a clean removal option. Dependencies are the problem, since different distros (even based on the same package format) have different libraries and may not be entirely compatible.
2: Files under /etc can be backed up and restored... Well, the registry can be, too. Powershell gives you a shell scripting interface to it. I wouldn't say the registry is a perfect system but it does have its merits. What's nice about putting this stuff on the filesystem is it's relatively easy to explore - but this is mainly a matter of naming and style. In the registry a lot of things are referred to by GUID - which has the advantage of avoiding name clashes (whether from different apps or different versions of the same app) - but the disadvantage of being totally unreadable. QX, the registry was designed for machines, while /etc is more of a compromise between machines and users. What would be useful IMO is a compromise that still provides more of the advantages of GUID use and compact binary representation, without losing the user-accessibility at the shell level.
I think the name clashing issue is a real problem. In a filesystem, one expects everything to have a name (even if there is no sensible choice for a "name" for the thing) - and every name has to be unique, and the uniqueness of any given thing is purely a function of that name. This is a strategy that doesn't scale well. If two groups decide to give different things the same name, there's no sorting that out, it's simply a conflict. For now this works out reasonably well, not too many name clashes in programs, libraries, or configuration files... But the strength of all the GUID use in Windows is that these identifiers are smaller than most filenames but do a better job of distinguishing entities.
3: Kernel ABI
I'd add that the application ABI isn't entirely stable, either... Implementation changes in libstdc++ (within the same major version number, even!) mean that if you build something in one version of g++, and build something else in another version of g++, you can't rely on being able to dynamically link the two together. The result could be dangerous library symbol imposition resulting in, for instance, erroneous allocation handling or a crash. As with many of these issues it isn't a "Linux" (kernel) issue but something developers have to deal with when programming for Linux-based systems. I've always found the handling of symbols between dynamically-linked modules a bit problematic, really...
4: File Versioning
To me the issue here isn't the presence or absence of the feature (it's present in some form, I guess) - the more important issue is that, like xattr's, these aren't taken as a default assumption by most of the programs people regularly use. The features are there but mostly unutilized. This will take a lot of time to change.
6: I'm not clear on what features the guy wants the kernel (or some set of standard libraries) to provide to all GUIs. Object brokership? (I would like that, I think...) Something else?
7: His point was more about what happens after X crashes, I think - saying that what can be salvaged of your working session should be. But it is. The X server crashes, the programs realize they don't have a connection to a display server any more, and they shut down. Unless the apps themselves are crashed, they still have the ability to do a clean shutdown, save state, etc...
fuck that! If I ever see programs like cp become bloated with X library calls because some news reporter needs to see a GUI progress bar, I'm going to be very angry.
OK, but consider this...
Imagine that it's the shell that contains all that complicated stuff for managing a UI, handling progress bars, etc. - and programs running in the shell have a relatively lightweight way to report status updates to the shell.
Basically, I argue that "cp" shouldn't be an X program, but rather the shell should provide it with a simple way to display a progress report, which the shell would implement properly for different display types.
Obviously for a solution like this there's some forethought required, to choose the desirable trade-off point between functionality and simplicity... And a feature like this can't possibly serve every scenario perfectly. But if we step away from the idea of what a "terminal" traditionally has been, and think about what kind of data channels we want, what kind of relationship we want, between the program we run, the shell we run it in, and the display we use to interact with it... I think it's worth revisiting that. Is the current solution, where a program's output is expected to serve as both user display and data output for further processing, really sensible? It seems to me that chaining the two together limits both: the user display is limited by the need to have it be processable, and kept inflexible for reasons of compatibility... And for processing, the data format can't be made more efficient because that would interfere with its double-duty as raw-form UI.
Fark picked Keanu Reeves as the "robot actor." A more fitting pick, I believe.
Keanu Reeves Happy - :-| :-| :-|
Keanu Reeves Sad -
Keanu Reeves Really, Really, Angry -
"Whoa."
Sigh... if you're going to quote Douglas Adams, at least quote him correctly:
Arthur: "What's so unpleasant about being drunk?"
--Hitchhiker's Guide to the Galaxy, Chapter 6
Maybe I'm a little thick-headed, but I'm pretty sure I got it right. I wrote:
"What's so unpleasant about being drunk?"
You wrote:
Arthur: "What's so unpleasant about being drunk?"
Looks like an exact match to me...
Rugby gets its name because it is as entertaining as receiving a rugburn.
Well, you know, a lot of the common ways one might receive a rug burn are well worth it...
How would slashdotters feel if somebody started selling a Linux branded cabernet with a picture of Tux on it without permission?
Most likely? Drunk.
What's so unpleasant about being drunk?
Case 3: The Neanderthal is as smart as we are.
Fuck. We have all the problems of Case 2, and more. We just made a person that is, by definition, part of the world's smallest and loneliest minority. He or she will never be able to live a remotely normal or fulfilling life.
That's assuming quite a lot, isn't it? Lots of people are born into unfortunate circumstances - not all of them wind up miserable and dejected for their entire life.
I think this whole situation really illuminates the valuable services provided by the Mad Scientist community. Others may laugh, or say that they're toying with forces man was not meant to comprehend... But they perform the science others don't dare attempt. And the price they pay, they earn the hatred of all those who didn't want to see the experiments done in the first place... Maybe they wind up buried under tons of lava after a well-dressed gentleman pays a visit to their secret volcano lair... It's a hard life, but they endure it, out of love of the game and their firm belief in the importance of science...
It's just an old wise tale carried over from the 19th century that still haunts us today (as seen here).
An "old wise tale"?
I for one welcome our previously extinct smarter overlords.
A planet where APES EVOLVED FROM MEN??
IT'S A MADHOUSE! A MAAAD HOOUSE!
Yeah, but this requires just 3 lightbulbs worth of power (or whatever) - Moisture Vaporators need Power Converters, and then there's the trip to the Toshi station. No comparison, really.
And more importantly, Moisture Vaporators only speak Bocce - so unless you know the difference between "raffa" and "volo" you're out of luck.
Rather than focus on taking the cell phones away, we should ask ourselves: what good is a phone call if you can't talk?
...Well, I guess the answer to that is that you could still text somebody, or use a TDD device or a modem, maybe fax something, or play songs on the touch tones like in Short Circuit 2, etc...
Oh yeah, and rigging it so prisoners can't speak might be slightly evil. We should examine the implications there before we do anything...
First, I can put together an AMD box equivalent to an Intel for about $200 bucks cheaper. That money goes into my Video Card and I wind up with a better overall System.
I just bought a new computer, looking at quad-core configurations from either Intel or AMD - and, granted, I'm not so in-touch with computer hardware as I used to be - but my impression from the reviews I'd seen, etc. was that AMD was slightly slower per clock-cycle than Intel, and that the range of available clock speeds didn't go as high, either. The one advantage AMD had was a better memory architecture... Which, given the fact that this is a quad-core system, is very important if you don't want the problem to be dominated by a bunch of cache misses - but still my impression was that the Intel offerings were stronger at the current time...
http://www.merriam-webster.com/dictionary/fail%5B2%5D
Main Entry:
2fail
Function:
noun
Date:
13th century
1 : failure --usually used in the phrase without fail
2 : a failure (as by a security dealer) to deliver or receive securities within a prescribed period after purchase or sale
Right. Which of those two uses was this again?
"What's it called?" he asked.
"My Name Is Earl."
"I thought your name was Steve?"
"THIRD BASE!"
Vista is an epic fail!
If I could, I would mod -1: bad taste for using "fail" as a noun...
I don't know - in my experience usually the new price of the old game has lowered, too.
I very rarely (almost never) buy used games in a game store, because honestly I just don't think they offer a very good price on them. It'll be like new copy: $60, used copy: $55. Or if it's an older game it might be new copy: $30, used copy $25.
Now from a practical standpoint I don't care at all whether it's a new or used copy. There hasn't been a significant difference in quality in my experience. Plus I own a smallish house, I really can't take more accumulation of "stuff" - so in many cases I don't even keep things like the DVD case or manual. But if the price difference is so minor, it becomes a matter of principle: I don't want to pay new game prices for used games. The previous owner of the game got something out of the deal, the game store gets something out of the deal, I want something out of the deal, too. Like a real non-trivial savings.
You can't video conference with a pencil.
Let's just take a moment to appreciate that sentence. In how many circumstances would a sentence like this be useful? How frequently can you imagine someone needing this point cleared up? It seems a delightful absurdity, and the fact that it developed out of the natural course of this discussion is highly enjoyable.
Oh boy.
No, no, no... you got it all wrong... you're supposed to save "Quantum Leap" references for discussions about "Enterprise"...
Watching that trailer it seems like they've made an effort to sex-up trek
have you seen the TOS?
seriously.
star trek had scantily clad women in almost every episode, with barely veiled (for the time) bouts of kirk scoring with every single one of them.
I'd just like to say, thank you, William Ware Theiss, wherever you are...
I can see where you are coming from, but an issue with Trademark is that it has to be exact. Using the name XEvil, and adding a surname to it sounds like, at LEAST, the original creator was endorsing your work or had some level of involvement. IceWeasel is not Firefox, and it is more than the opposite of the name.
My point is not about trademark or copyright, it is about respect.
Mutant Strain truly was a version of XEvil. I changed some things and added some things and made my own fork but it was the same game. The issue there was that I wasn't courteous in how I managed and promoted my fork. What I did with the game (apart from some mistakes I made in earlier versions of the fork, like remove the original author's credit entirely) was in line with the game's original GPL license, but it wasn't nice.
Likewise IceWeasel: as I said, I never really thought the name was disrespectful, but I can see how it could be taken that way. I don't think that name necessarily needs to be changed - but if this perception that it's a derisive or spiteful name choice is a common one then something should be done to address that: after all, free software depends on cooperation. Cooperation isn't just a matter of slapping a free software license on a program, it's about people showing each other courtesy and respect in how they deal with each other.
Hello? Mods on crack!
iceweasel was kind of a dick move from developers that didn't want to live up to the same expectations as everybody else.
I'm not certain why you think it's a "dick move" to do something that you're allowed to do. But I AM certain that they are living up EXACTLY to the same expectations as everyone else.
Oh! I can field this one... As someone who once made a fairly shitty, uncourteous move myself...
See, back in the late 90s I made a fork of the game XEvil. XEvil v1 was GPL'ed, while XEvil v2 was not. I forked a late version of v1 and called it "XEvil Mutant Strain" - added some characters and weapons and stuff, put my name on it, etc. It even wound up on a CD release of Linux games.
So why was this a shitty thing to do? Basically, during all this, I wasn't thinking in terms of how to be courteous to the original author of the software. In the case of Mutant Strain it was like "I'm gonna fork this 'cause I don't approve of your new license" - followed by a lot of shoddy work, and promotion of said shoddy work, using the name XEvil and without being courteous or thankful for the original code I was working from. I didn't do enough to distinguish my project as a fork and I didn't do enough to recognize the original author.
So I can appreciate the perspective from which someone says it was a shitty move to call the fork IceWeasel. I never really thought of it like that before - mostly I just thought the name choice was kind of funnny. But the fact that the name choice is kind of a parody (especially given all the name changes Firefox was subject to early on) is kind of ungrateful in a way - almost like the people who chose the name wanted to express spite toward the Firefox folks for creating the condition in which they couldn't change the source to fit their distribution and still call it Firefox. I think a more appropriate attitude is continuing thanks for making Firefox source free in the first place, even if there are uncomfortable limitations.
You could hand Stallman a can of beer, gratis, and he'd say it wasn't free because it had a trademark on the label and the recipe wasn't open-source.
I bet he'd drink it, though.
But Stallman doesn't like the "Open-source" terminology or the philosophy that drives it!