They do keep a list of servers whose administrators that does not want to cooperate in the fight against spam for whatever reason.
It is up to the mail server administrators to decide whether they want to accept mail from those servers. That is a perfectly fair and honorable thing to do.
Why excatly do you think I should be denied the choice to refuse to accept mail from people who will not help fight the one thing that have made mail nearly useless to me?
And why exactly do you think that giving me that choise is as morally questionable as trying to force me to accept and pay for junk I don't want?
The real problem is that Netscape and to a lesser degree Microsoft have been bending over backwards to give full control of the presentation to the content provider, against the original idea of HTML to let the content provider describe the content, and leave the presentation to the user, or the software acting on his behalf.
Such traps are just the absurd symptoms of how control of the users machine have been taken away from the user, and given to the content provider. The real way to combat this is to tranfer control back to the user, and demand content based markup over presentation based markup.
It also means less developer ressources to spend per compiler. It isn't like a new compiler suddenly make more people (or money) interested in doing development.
Gtk-- is by far the most elegant. It actually uses C++ as it is intended to be used, giving a statically typesafe interface unlike Qt, and not depending on ugly special purpose preprocessor hacks.
However, Qt is way more comfortable. Stable well documented API's beats any amount of elegance, and the ugly hacks are easy to use. The lack of static typesafety is something most programmers are used to deal with.
I switched from Gtk-- to Qt and haven't regretted it, it gets the work done, but sometime the academician in me miss the superior elegance of Gtk--.
does not inspire confidence. Not just because of the hybris (or the movie indoctrination where nemesis always follows that kind of hybris). But because it is not the sort of thing real scientists say.
Real scientists know their understanding is always (and will always be, it is mathematically proven (by Gödel)) incomplete.
And they are not shy of saying so. "Our understanding is now complete" is no way to ensure funding for new reasearch. Think about it.
They are in Europe. I don't think they ever did suicide missions. Nor do the right wing terrorists, which make me believe it is religious groups. Suicide missions are so much more compelling when you believe paradice waits as a reward.
It was created by the US to fight the Soviet intervention force (slightly simplified). It is unclear who would (or could) provide similar support for taliban if US invaded afganistan.
Emacs can be invoked as both a GUI and CLI[1] tool, and certainly qualifies as an IDE, even if it is not for everyone.
The answer is pretty simple. Emacs in GUI mode can do everything Emacs in CLI mode, and often has several ways to do stuff that are missing in CLI mode. These alternative ways are sometimes useful, and when not, one just use the CLI way that is still available. So a GUI is preferable to a CLI, given the same basic featureset.
It is as simple as that. The reason some people can make an issue of it, is that they are comparing radically different environments, with radically different features. With Emacs, one can isolate the CLI/GUI factor.
BTW: Some people (often people who haven't used a recent or properly configured Emacs) claim Emacs isn't a "real" GUI tool. Objectively, they are wrong, it uses the native window system and has (at least in some versions) all the features traditionally expected from a GUI tool. However, these relatively new GUI features aren't always fully utilized by the various Emacs subsystems. The advantages of GUI Emacs is only going to grow as these subsystems utilize the new fascilities.
[1] Provided we allow full screen tools like vi, and doesn't restrict CLI to pure line oriented tools like ed.
> Nice post! I showed it to Linus Torvalds and,
> though it was hard for him, he finally agreed
> to scrap Linux and work on the HURD. One battle
> won!
Hurd development wasn't very open, so that might have been hard.
> I'm going to talk to Bram Moolenaar next,
> because I'm pretty sure there was another vi
> clone before vim.
Plenty, I believe both elvis and vile are older than vim.
1. Speed of compiler.
2. Size of generated code.
3. Speed of generated code.
When comparing gcc 2.95 and gcc 3.0 with regard to inlining alone, the gcc 3.0 inliner is worse on all three counts. They changed the inliner to apply earlier (at the tree level instead of at the rtl level), which gives it far more oppertunities for inlining. This results (for C++ that uses STL) in order of magnitude slower compiles, several times larger binaries, and, because of cache misses and pipelining issues, significantly slower executables.
The problem is that the old inlining heuristics doesn't work with the new (and potentially much better) inliner. As a band-aid, they decreased one of the old parameters in 3.0.1, the inline limit. This avoids the huge compile times and binaries, but also sometimes misses important inlines. Exactly when you get the important inlines, but without the ridiculous inlines, depend on the application. Sometimes you can't.
For 3.1 the GCC developers will install all new inlining heuristics, which will hopefully be consistently better than 2.95. The potential is there with the new tree-based inliner.
In hindsight, it was probably a mistake to release gcc 3.0 before without the new inline heuristics, however 3.0 was already delayed, and is much better for most code.
I have one source file which takes almost a day to compile with 3.0 at -O3. It isn't particular long (2k lines) or advanced. The rest of the project (~150 files) takes maybe 6 hours to compile. I don't know why that file is hit so hard.
In any case, I switched back to 2.95. SUre, I cpmile without optimization most of the time, but I like at least to test the program with optimization once or twice a week, to catch any bugs that are only triggered by the optimizer.
Obviously, a day (or even 6 hours) is not acceptable in those circumstances.
Several people on the GCC list have tried to optimize -finline-limit, and they have come to very different conclusions. It totally depend on the application. Setting it to 5000 may very well slow the resulting code a lot compared to the default. Try for youself.
Basically, the inline code have been rewritten in 3.0 (to work on trees instead rtl), which gives a lot more oppertunities for inlining and for further optimizations. However, the old heuristics for inlining have not been adopted to the new code, which means way to much code is inlined in 3.0, which again means much slower compile times, fatter binaries, and even slower binaries because of more cache misses.
In 3.0.1 the inline limit was set down to cure the worst symptoms. However, what is really needed is new heuristics, which will be in 3.1.
Slashdot Mirror
They don't arbitrarily blackhole any companies.
They do keep a list of servers whose administrators that does not want to cooperate in the fight against spam for whatever reason.
It is up to the mail server administrators to decide whether they want to accept mail from those servers. That is a perfectly fair and honorable thing to do.
Why excatly do you think I should be denied the choice to refuse to accept mail from people who will not help fight the one thing that have made mail nearly useless to me?
And why exactly do you think that giving me that choise is as morally questionable as trying to force me to accept and pay for junk I don't want?
OpenOffice is free software, so if you are a programmer, you can help with #1 and #2.
Since you obviously can write, you can help help with #3 as well.
I guess you are already helping with #4.
The real problem is that Netscape and to a lesser degree Microsoft have been bending over backwards to give full control of the presentation to the content provider, against the original idea of HTML to let the content provider describe the content, and leave the presentation to the user, or the software acting on his behalf.
Such traps are just the absurd symptoms of how control of the users machine have been taken away from the user, and given to the content provider. The real way to combat this is to tranfer control back to the user, and demand content based markup over presentation based markup.
It is NOT the code that is banned, it is a particular use of the code that is banned.
This is how DeCSS should have been handled, the code itself should be legal, but using it to make unauthorized copies of DVD's should be illegal.
Using DeCSS to play DVD's or to make copies under "fair use" should be legal, of course.
(sorry for shouting)
It also means less developer ressources to spend per compiler. It isn't like a new compiler suddenly make more people (or money) interested in doing development.
Fort older code, "install GCC" simply mean "don't use the braindamaged pre-ANSI C compiler bundled with the system."
If so, it can reasonably be maintained as an add-on to the standard kernel.
While you don't want the same os on a mainframe and a wrist watch, it can reasonably be two configurations of the same OS framework.
I have used both, and you are half right.
Gtk-- is by far the most elegant. It actually uses C++ as it is intended to be used, giving a statically typesafe interface unlike Qt, and not depending on ugly special purpose preprocessor hacks.
However, Qt is way more comfortable. Stable well documented API's beats any amount of elegance, and the ugly hacks are easy to use. The lack of static typesafety is something most programmers are used to deal with.
I switched from Gtk-- to Qt and haven't regretted it, it gets the work done, but sometime the academician in me miss the superior elegance of Gtk--.
Such a card would simply be too convenient for way to many tasks, so everybody would require it.
Nonetheless, I want it in my country. Fuck privacy, I want convenience.
Most appliances already come with pages of legalize nobody reads. Two more pages (for the GPL and offer to procide source) won't make a difference.
... or at least the article said so.
Someone in the mozilla.license group explained it this way:
1. GPL coplefts an application.
2. LGPL copylefts a library.
3. MPL copylefts a file.
The distinction is merely how far the copyleft aspect of the licenses reached
does not inspire confidence. Not just because of the hybris (or the movie indoctrination where nemesis always follows that kind of hybris). But because it is not the sort of thing real scientists say.
Real scientists know their understanding is always (and will always be, it is mathematically proven (by Gödel)) incomplete.
And they are not shy of saying so. "Our understanding is now complete" is no way to ensure funding for new reasearch. Think about it.
They are in Europe. I don't think they ever did suicide missions. Nor do the right wing terrorists, which make me believe it is religious groups. Suicide missions are so much more compelling when you believe paradice waits as a reward.
It was created by the US to fight the Soviet intervention force (slightly simplified). It is unclear who would (or could) provide similar support for taliban if US invaded afganistan.
Emacs can be invoked as both a GUI and CLI[1] tool, and certainly qualifies as an IDE, even if it is not for everyone.
The answer is pretty simple. Emacs in GUI mode can do everything Emacs in CLI mode, and often has several ways to do stuff that are missing in CLI mode. These alternative ways are sometimes useful, and when not, one just use the CLI way that is still available. So a GUI is preferable to a CLI, given the same basic featureset.
It is as simple as that. The reason some people can make an issue of it, is that they are comparing radically different environments, with radically different features. With Emacs, one can isolate the CLI/GUI factor.
BTW: Some people (often people who haven't used a recent or properly configured Emacs) claim Emacs isn't a "real" GUI tool. Objectively, they are wrong, it uses the native window system and has (at least in some versions) all the features traditionally expected from a GUI tool. However, these relatively new GUI features aren't always fully utilized by the various Emacs subsystems. The advantages of GUI Emacs is only going to grow as these subsystems utilize the new fascilities.
[1] Provided we allow full screen tools like vi, and doesn't restrict CLI to pure line oriented tools like ed.
Right now, they can stop you if they suspect you for drunk driving, with no real evidence at all.
If this system became common, they would need to stop less innocent people in order to catch the same number of drunk drivers.
Still more efficient than stoping people at (mor or less) random, as is the case now.
> Nice post! I showed it to Linus Torvalds and,
> though it was hard for him, he finally agreed
> to scrap Linux and work on the HURD. One battle
> won!
Hurd development wasn't very open, so that might have been hard.
> I'm going to talk to Bram Moolenaar next,
> because I'm pretty sure there was another vi
> clone before vim.
Plenty, I believe both elvis and vile are older than vim.
1) US is pressuring the rest of the world, through WTO, to accept software patents.
2) Even in the cases where Debian would win in a court, they might not have the money to run the case.
There are three issues
1. Speed of compiler.
2. Size of generated code.
3. Speed of generated code.
When comparing gcc 2.95 and gcc 3.0 with regard to inlining alone, the gcc 3.0 inliner is worse on all three counts. They changed the inliner to apply earlier (at the tree level instead of at the rtl level), which gives it far more oppertunities for inlining. This results (for C++ that uses STL) in order of magnitude slower compiles, several times larger binaries, and, because of cache misses and pipelining issues, significantly slower executables.
The problem is that the old inlining heuristics doesn't work with the new (and potentially much better) inliner. As a band-aid, they decreased one of the old parameters in 3.0.1, the inline limit. This avoids the huge compile times and binaries, but also sometimes misses important inlines. Exactly when you get the important inlines, but without the ridiculous inlines, depend on the application. Sometimes you can't.
For 3.1 the GCC developers will install all new inlining heuristics, which will hopefully be consistently better than 2.95. The potential is there with the new tree-based inliner.
In hindsight, it was probably a mistake to release gcc 3.0 before without the new inline heuristics, however 3.0 was already delayed, and is much better for most code.
I have one source file which takes almost a day to compile with 3.0 at -O3. It isn't particular long (2k lines) or advanced. The rest of the project (~150 files) takes maybe 6 hours to compile. I don't know why that file is hit so hard.
In any case, I switched back to 2.95. SUre, I cpmile without optimization most of the time, but I like at least to test the program with optimization once or twice a week, to catch any bugs that are only triggered by the optimizer.
Obviously, a day (or even 6 hours) is not acceptable in those circumstances.
Several people on the GCC list have tried to optimize -finline-limit, and they have come to very different conclusions. It totally depend on the application. Setting it to 5000 may very well slow the resulting code a lot compared to the default. Try for youself.
Basically, the inline code have been rewritten in 3.0 (to work on trees instead rtl), which gives a lot more oppertunities for inlining and for further optimizations. However, the old heuristics for inlining have not been adopted to the new code, which means way to much code is inlined in 3.0, which again means much slower compile times, fatter binaries, and even slower binaries because of more cache misses.
In 3.0.1 the inline limit was set down to cure the worst symptoms. However, what is really needed is new heuristics, which will be in 3.1.
Oops, that was an unintended double negation.
Last time I checked kiro5hin, the "front page" looked like reading /. at -1.