C'mon guys. Entertainment value aside, even assuming the interpretation is correct (and it looks right, I'll admit) there's no way this was intended. In a few days the TOS will change again, and we'll be telling jokes about AOL for years to come. Well, more jokes, anyway.
Don't get me wrong -- eternal vigilance and all that. If it hadn't been caught, it probably would have stayed there forever. It just goes to show that no one reads these things, including the people who write them.
I read the names immediately, but it took a while for me to recognize them. Yes, it seems likely now that the foundation has somehow been blocking these things. New management will help.
The Mozilla Foundation has been looking for people to work on the Mozilla Suite for a while now. Nothing prevented people from doing work on it.
That it was killed indicates there just wasn't enough support to continue it.
Thus, the help for the community is limited to those who either were not aware help was needed, or are willing to work on a rebranded Mozilla Suite (it's trademarked, isn't it?) but not on the original Mozilla Suite while the Mozilla Foundation drove it.
In short, new developers and people who fork for the sake of forking.
If Mozilla Suite had community enough to support it, they would have been integrated into the Mozilla Foundation to begin with. That it's been dropped like this shows there are plent of people willing to talk about supporting it, but not enough people willing to actually do it.
Mind you, maybe this will shake some supporters out that didn't realize things were in such rough shape.
Who cares about this new fangled FM radio stuff. One channel is enough for anyone! Give me a call (on my crank phone) when you can get a portable MP3 player that can fit in your pocket and play vinyl records (LPs, not singles).
I have to disagree about MediaWiki. More and more, I think it's the next "killer app" -- collaborative document editing with built-in revision tracking: true HyperText at last after 40 years. But yes, that's hard to explain to people.
As for OpenOffice.org, about the most exciting feature is the compressed XHTML file format, which isn't a big sell to real-world users.
Maybe the II and III were okay, but as someone who spent about 30 hours trying to code a workaround to the HP 4's buggy-as-shit layout engine, I really have to object to them being done right.:)
The third way to look at this is that Free Speech has won the day. To this way of thinking, another attempt to squash the little guy with a big mouth has failed.
That's a load.
Free speech does not give someone the right to make a newspaper run their story, nor make a tv network run his shitty programming, nor make the postal service deliver his flyers for free, nor make my email server carry his message. That the scale of spamming is larger than the other threeexamples does not excuse it. If he wants my email server to carry his message, he can negotiate with me. But I have every right in the world to tell him "No."
Spam is not a free speech issue. Spam is a denial/theft of service issue.
To play devil's advocate for a moment, haven't we already decided that's true of cell phone providers?
For the record: I think calling this a free speech issue is misleading, but that doesn't mean I think it isn't an issue that should result in some heads rolling.
I had something similiar happen here. I finally cut loose and told everyone who would listen (including my manager) how badly off-course our product plan was.
After a while, they agreed, but said there wasn't much to be done about it because of our contract. But after that, they started looking for chances to steer a bit.
I just finished writing a feature list for the next version. I feel that every one of those features will improve customers' lives, at least to some degree, and the features represent the stuff that is actually being asked for, rather than half-baked suggestions from the poorly worded SARs. I'm still not thrilled (they're insisting on a series of very small releases, which leaves us with a lot of overhead) but life has become tolerable at least.
I agree, it's a lousy deal when you want the whole album. But if I'd bought Old Habits Die Hard, I would have saved the cost of the rest of the album... even if I'd bought all three versions of the track, I'd still be ahead.
If it makes you feel like a better person, go right ahead!
If I was rewriting this code from scratch, I'd reconsider the variable names. I might end up with underscores_like_this for variables. So the variables in the example I gave would be task_count and task_i.
But I definitely wouldn't use the same convention for variable names vs. other identifiers.
I couldn't agree more. I recently wrote some routines for a 68000. My original implementation took 2 seconds for my test case. Once I studied and improved my algorithm a bit more, I not only got the time down to 0.29 seconds, but improved the accuracy of the alogirthm as well.
I did this before porting the code to a much faster achitecture (you can choose between 68000 or ARM code on the Palm). Just for the fun of it, I posted both algorithms. The original algorithm came in at 0.83 seconds, and the optimized one at 0.04 seconds. So I gained more by tuning the algorithm than by switching out of the emulated environment to the real one!
This last point is the basis for most "Java is faster than C!" arguments, and doesn't take into account that you can usually tune the C code as well. (Not saying Java is slow, mind you, just that it's not faster.)
I was sharing what I did, not saying I am an authority. My point is just what you are trolling -- there is no absolute authority on matters of coding style.
Although I do maintain that you should follow the coding standard of whatever project you are working on, and this statement is echoed on the GNU web page somewhere (along with their recommendation to use their style on new projects). (No, I'm not going to look up where again.)
An important lesson that I wish I had learned when I was younger;) It is crazy to start optimizing before you know where your bottlenecks are. Don't guess - run a profiler. It's not hard, and you'll likely get some big surprises.
Another thing to remember is this: the compiler isn't stupid; don't pretend that it is.
Correction: Some compilers aren't stupid. Others are. I used to rely on compilers to optimize my code. Metrowerks Codewarrior taught me otherwise.
Consider what you need the code to do.
Consider the algorithm you plan on using.
Write the code.
Make sure it works according to #1.
Save the code to your repository.
Eliminate redundant operations and unroll calculations (whether integer or floating point) in loops when possible.
Make sure it still works according to #1.
Save the code to your repository.
Rather than guessing if the compiler has done a good job of compiling it, dump the produced object code and read through it. Among other things, the altenrate way of describing your code may help you spot situations you didn't think of while writing the source.
Make sure it works according to #1.
Save the code to your repository.
Leave it alone for now, but profile it later.
Is it necessary? Well, maybe not, and it certainly doesn't replace profiling. But it certainly isn't crazy to check your code carefully when you write it. (If you have to do only one, though, certainly profiling is the more important of the two.)
With the greatest respect to Linus, but writing a kernel does not make you the authority on programming. It does make you the authority on what particular style you allow in your CVS tree, but that's it.
I certainly agree that loop_counter is a bad name, though. But rather than use i, I prefer to at least make a note of what sort of objects I'm looping through.
For instance:
int taskI; int taskCount = GetTaskCount(); for (taskI=0; taskI<taskCount; taskI++) { ... }
Code can never be 100% self documenting, but that's no reason not to settle for 0%. Whether you use CamelCase or words_broken_with_underscores is a matter of style, and you should stick with the style of the code base you're working on.
Anyone who can't or won't work with multiple languages or adopt the necessary style for an existing project is a poor programmer. When you create project, you create the rules. When you work on someone else's project, you follow the rules.
Slashdot Mirror
If people try to steal copies of the release version, they'll probably get sued as well. And maybe criminally charged, too.
And why not? It isn't like they need their eyes for reading the TOS, is it?
C'mon guys. Entertainment value aside, even assuming the interpretation is correct (and it looks right, I'll admit) there's no way this was intended. In a few days the TOS will change again, and we'll be telling jokes about AOL for years to come. Well, more jokes, anyway.
Don't get me wrong -- eternal vigilance and all that. If it hadn't been caught, it probably would have stayed there forever. It just goes to show that no one reads these things, including the people who write them.
I read the names immediately, but it took a while for me to recognize them. Yes, it seems likely now that the foundation has somehow been blocking these things. New management will help.
I hope you're right. I don't use the suite myself, but I think it's important to have. (At least for a few more years.)
The Mozilla Foundation has been looking for people to work on the Mozilla Suite for a while now. Nothing prevented people from doing work on it.
That it was killed indicates there just wasn't enough support to continue it.
Thus, the help for the community is limited to those who either were not aware help was needed, or are willing to work on a rebranded Mozilla Suite (it's trademarked, isn't it?) but not on the original Mozilla Suite while the Mozilla Foundation drove it.
In short, new developers and people who fork for the sake of forking.
If Mozilla Suite had community enough to support it, they would have been integrated into the Mozilla Foundation to begin with. That it's been dropped like this shows there are plent of people willing to talk about supporting it, but not enough people willing to actually do it.
Mind you, maybe this will shake some supporters out that didn't realize things were in such rough shape.
Okay, so that takes us up to 2% of open source developers making enough money to stay alive.
By that logic, Linus used to run Linux on Linus, since a PC was the hardware.
Let's review:
......Zzzzzzzzzz. Snerk!
Who cares about this new fangled FM radio stuff. One channel is enough for anyone! Give me a call (on my crank phone) when you can get a portable MP3 player that can fit in your pocket and play vinyl records (LPs, not singles).
Otherwise, nuts on you!
Snerk! Zzzzzzzzzz.......
Yes. Humans really only have one way of solving large problems: Divide and conquer.
I have to disagree about MediaWiki. More and more, I think it's the next "killer app" -- collaborative document editing with built-in revision tracking: true HyperText at last after 40 years. But yes, that's hard to explain to people.
As for OpenOffice.org, about the most exciting feature is the compressed XHTML file format, which isn't a big sell to real-world users.
Or the LemkeSoft response, six hours later:
Hi! Good idea. Attached is a beta. Tell me how it works for you.
Maybe the II and III were okay, but as someone who spent about 30 hours trying to code a workaround to the HP 4's buggy-as-shit layout engine, I really have to object to them being done right. :)
The third way to look at this is that Free Speech has won the day. To this way of thinking, another attempt to squash the little guy with a big mouth has failed.
That's a load.
Free speech does not give someone the right to make a newspaper run their story, nor make a tv network run his shitty programming, nor make the postal service deliver his flyers for free, nor make my email server carry his message. That the scale of spamming is larger than the other threeexamples does not excuse it. If he wants my email server to carry his message, he can negotiate with me. But I have every right in the world to tell him "No."
Spam is not a free speech issue. Spam is a denial/theft of service issue.
To play devil's advocate for a moment, haven't we already decided that's true of cell phone providers?
For the record: I think calling this a free speech issue is misleading, but that doesn't mean I think it isn't an issue that should result in some heads rolling.
I had something similiar happen here. I finally cut loose and told everyone who would listen (including my manager) how badly off-course our product plan was.
After a while, they agreed, but said there wasn't much to be done about it because of our contract. But after that, they started looking for chances to steer a bit.
I just finished writing a feature list for the next version. I feel that every one of those features will improve customers' lives, at least to some degree, and the features represent the stuff that is actually being asked for, rather than half-baked suggestions from the poorly worded SARs. I'm still not thrilled (they're insisting on a series of very small releases, which leaves us with a lot of overhead) but life has become tolerable at least.
I agree, it's a lousy deal when you want the whole album. But if I'd bought Old Habits Die Hard, I would have saved the cost of the rest of the album... even if I'd bought all three versions of the track, I'd still be ahead.
Don't choosy web developers choose PNG?
If it makes you feel like a better person, go right ahead!
If I was rewriting this code from scratch, I'd reconsider the variable names. I might end up with underscores_like_this for variables. So the variables in the example I gave would be task_count and task_i.
But I definitely wouldn't use the same convention for variable names vs. other identifiers.
I couldn't agree more. I recently wrote some routines for a 68000. My original implementation took 2 seconds for my test case. Once I studied and improved my algorithm a bit more, I not only got the time down to 0.29 seconds, but improved the accuracy of the alogirthm as well.
I did this before porting the code to a much faster achitecture (you can choose between 68000 or ARM code on the Palm). Just for the fun of it, I posted both algorithms. The original algorithm came in at 0.83 seconds, and the optimized one at 0.04 seconds. So I gained more by tuning the algorithm than by switching out of the emulated environment to the real one!
This last point is the basis for most "Java is faster than C!" arguments, and doesn't take into account that you can usually tune the C code as well. (Not saying Java is slow, mind you, just that it's not faster.)
I was sharing what I did, not saying I am an authority. My point is just what you are trolling -- there is no absolute authority on matters of coding style.
Although I do maintain that you should follow the coding standard of whatever project you are working on, and this statement is echoed on the GNU web page somewhere (along with their recommendation to use their style on new projects). (No, I'm not going to look up where again.)
An important lesson that I wish I had learned when I was younger ;) It is crazy to start optimizing before you know where your bottlenecks are. Don't guess - run a profiler. It's not hard, and you'll likely get some big surprises.
Another thing to remember is this: the compiler isn't stupid; don't pretend that it is.
Correction: Some compilers aren't stupid. Others are. I used to rely on compilers to optimize my code. Metrowerks Codewarrior taught me otherwise.
Is it necessary? Well, maybe not, and it certainly doesn't replace profiling. But it certainly isn't crazy to check your code carefully when you write it. (If you have to do only one, though, certainly profiling is the more important of the two.)
With the greatest respect to Linus, but writing a kernel does not make you the authority on programming. It does make you the authority on what particular style you allow in your CVS tree, but that's it.
I certainly agree that loop_counter is a bad name, though. But rather than use i, I prefer to at least make a note of what sort of objects I'm looping through.
For instance:
Code can never be 100% self documenting, but that's no reason not to settle for 0%. Whether you use CamelCase or words_broken_with_underscores is a matter of style, and you should stick with the style of the code base you're working on.
Anyone who can't or won't work with multiple languages or adopt the necessary style for an existing project is a poor programmer. When you create project, you create the rules. When you work on someone else's project, you follow the rules.
It's not only toll free, but 24 hour.
Mind you, I found talking to them to be a very painful experience, because they seemed to assume I was a thief. But they were easy to get ahold of.