Re:Recursive Make Considered Harmful Considered Du
on
Optimizing distcc
·
· Score: 1
That comment makes a spectacularly bad case. It provides no analysis to back up its wild claims. Approximately zero lines of the comment has to do with the paper, which it essentially mischaracterizes.
That paper makes a spectacularly bad case
It makes a fine case. The worst part is that it exaggerates the value of its own minor insight. The grandiose title harkens to the famous "Goto Considered Harmful", which in its time was a more insightful position.
Nobody should be surprised that globally correct choices cannot be decided with only locally correct data (for a non-greedy process, of course).
Moreover, the actual problems caused by suboptimal makefiles pales in comparison to what havoc goto can wreak. Anything wrong with makefiles can be solved by Moore's law (wait for the hardware to get faster, so you can do full rebuilds quickly). But spagetti code makes it more difficult for programmers to work with software, and there has been no observed exponential growth curve of human intelligence.
people write bad makefiles
That's a cop-out. The Makefile system has turned out to be too flexible for most needs. Because the build system relies on authors of individual make, the behavior of different Makefiles can be completely different (they're arbitrary programs, after all). That problem is analogous to the non-existent "package manager" on Microsoft Windows. Each Windows installer is an arbitrary program that might do anything, and whose actions cannot be reasoned about by software tools.
Furthermore, having one makefile in every directory is an almost assurewd way to produce bad makefiles.
which apply equally to recursive and monolithic ones.
Wrong. There is an inescapable difference in the performance (both speed and correctness). Recursive simply cannot compare with monolithic.
Note that "monolithic" doesn't necessarily mean the makefile is stored in only one file on disk. A collection of files assembled via include directives is equivalent to monolithic, but somewhat easier for revision control. Non-"make" build control processes, such as Ant or those provided with some IDEs, also share the advantages of monolithic makefiles.
The software industry has already demonstrated its support for RMCH, because all new "yet-another-better-than-make" projects take its ideas as unavoidable preconditions.
The point is that to a person unfamiliar with "compiler-intermediary" tools like distcc and ccache, the way to use them simultaneously is nonobvious.
Does the master host keep the cache, and farm out jobs on cache misses? Or does each box keep its own ccache, which is used to fulfill compilation jobs from the master? (Obviously, one of those options is drastically worse than the other)
Since you alluded to the possibility of distcc+ccache in the introduction, it is a disservice to your readers not to at least give a pointer to instructions on how to run them in tandem. At minimum, include this link. (And even better, add a disclaimed factoid on what your 6 minutes goes down to when ccache is in the mix)
The need for a Pilot License to operate a car-sized plane is being removed in the US. The new Sport Pilot categorization will let you fly a single-seater (bigger than an "ultralight") with only a driver's license and 1 week of intense instruction.
Gnome does not violate any patents (for starters, I've never seen a patent that broad).
Then I guess you haven't seen many patents. Spend an hour browsing uspto.gov for software patents, and I trust you'll see enough to disgust you. It looks as if nearly every nontrivial program falls under 4-6 patents from random large corporations.
The account I read stated known uranium mines could meet our current energy demands for a few decades.
Find a better account. If all power plants went uranium today, we'd last for 50 years, assuming no technological advancement.
If a machine is ever invented to pull uranium from seawater, we'd have three times as much (but that'd cost energy to run, so effectively just twice as much)
Most importantly, uranium can be created from other elements. Thorium is far more common than uranium, but can probably be transformed to uranium by part of the reactor system.
Related tech changes could let uranium reactors become more than 20 times as efficient as they are today, meaning the power would last for 1000 years. Then we can collapse into a tribal apocalypse in 3004!
The word "production" should never be used in reference to fossil fuels. The Middle East doesn't "produce" oil- it "extracts" it.
The inaccurate use of "produce" is one small way to keep the masses in denial about the obvious fact that oil is a non-renewable resource. Truthful speech will help the world mentally prepare to take the drastic steps necessary to move to a post-oil lifestyle.
(It also conceals the fact that nations like Iraq and Saudi Arabia don't and can't have an enconomy comprable to other nations with similar GNPs, as they merely sell off pre-existing assets)
For all of the people whining about the number of birds killed by power poles and cell phone towers, I encourage you to take a look at the number of birds killed by power-generating windmills.
Not only that, but it is a fallacy that the earth will ever "run out" of oil.
No, you're the one stating a fallacy. By oversimplfying to an incorrect definition of "run out", you have twisted the meaning of a claim. "Earth running out of oil" doesn't mean there are zero petroleum molecules left on the entire planet! It means we humans won't be able to acquire oil to use.
Consider a single modern automobile. As you drive it, petrol is used up. Does it ever run out of petrol? According to your argument, it never does, because there's always some miniscule amount left in the tank, even if it can't be reached for use.
The Romans invented a steam engine, but didn't bother to develop it because they had slaves.
Or prehaps more importantly, because they had no coal. Steam engines are much more effective running on coal than wood. When steam power was reinvented in England, the abundant coal mines made it quickly useful for heavy industrial tasks.
Yes, there are a lot more cars. That one reason why reducing automotive dependency is genuinely more important. Additional reasons:
Car owners use them nearly every day, while many trimmer-owners allow 10 or more days to elapse between using them.
Cars are used year round, while trimmers operate only in spring and summer
Cars are deeply ingrained to modern societies. If, for whatever reason, 95% of all trimmer-owners were made to cease usage for 50 days, no undue hardship would result. (The economic reaction would be a boost in income amoung chore-employed teenage boys) But obviously, 50 days without most cars would devastate any modern economy, leading to tremendous unemployment and disruption.
(most important) Burning fossil fuels has a twofold environmental damage. The pollution is caused is only part of the problem- and in many ways the lesser part. The actual permanent expenditure of unrecoverable petroleum is also damaging.
Environmentalists and "conservationists" (heard of them?) want to see cars used much less... not just to reduce pollution, but also so that there still exists gasoline for sale in 50 years!
there is nothing wrong with using different metaphors for different tasks.
Oh yes there is! Consistency of presentation has great value for UI systems.
Your example is particularly bad... it introduces some secret magic number of files which, when reached, may totally change the appearance of folder screen. (That's a bad thing)
But also, you said "for different tasks". Copying a file from A to B is essentially the same task, whether it's remote or local. Yes, the computer may go through drastically different hardware+softare pathways to actually do the copy, but those details are something we should strive to conceal from the end user.
the computer can do all that, and the user can benefit.
FAR more importantly, I don't recommend that anyone attempt to "keep up" with other platforms that violate patents.
That's an unrealistic viewpoint. There are just TOO MANY software patents out there for a developer to worry about avoiding them until the patent-holder initiates action. ("Willful ignorance" is the official policy of the Linux Kernel developers, who've had some formal legal advice on the matter)
For example, both Debian and Red Hat are violating patents by shipping GNOME, so should they stop that too on the off-chance of an enforcement?
Re:Spatial is a step backwards
on
GNOME 2.6 Reviewed
·
· Score: 4, Insightful
Spatial is a step backwards
Your experience with Gnome isn't enough evidence to to judge against "spatial" interfaces as a whole. As you noticed, the implementation is inconsistent- suggesting that the problem is not with "Spatial" itself, but that particular program.
However, pro-"Spatial" posters who jumped at you with "100% wrong" are also incorrect. In a deeper way, "Spatial" is truely a step backwards: because spatial filebrowsing is non-scalable.
It only works for small problems, where the total complexity is bounded. Back when the Mac was young and "Spatial" was in it's prime, users operated on single floppies or 100 megabyte HDs. The solutions that worked then become unbearably messy when a 100 gigabyte HD may have a quarter-million files.
And then there's networking. Considering that it may be useful to treat the drives of other computers or the whole internet with the same file-browser that handles your local data, and the quantity is just overwhelming.
Non-spatial file-views are the only way we can expect to view local and remote files through the same lense.
To make an analogy of a library: If you only have 20 books, then a card-catalog system is a waste of time. Just leave them out visible on a table, and let vistors find them "spatially". But with 20k books, the catalog is an important improvement, even though users can no longer retrieve volumes from "where I left it last time".
2. Windows servers can have multiple users logged in simultaneously, each with their own user interface. This capability is included in all Windows Server operating systems.
That is an invalid generalization. Windows Server operating systems are a subset of all Windows operating systems. A characteristic of the subset does not apply to the superset, so your comment doesn't reinforce the claim that "Windows is multiuser". If it were possible to get simultaneously logins with all current versions of Windows, then that would be significant.
(In reality, any OS can be considered multiuser if you install multiuser applications on it. Even MS-DOS had multiuser apps available.)
For stability, XFree is much nicer; if an app goes down or spins it's wheels looking for a resource, the rest of the system doesn't care one whit.
Untrue. It's still fairly easy for a program using XFree86 to freeze or crash the entire Xserver, killing any other process using it.
It is especially easy for one program to accidently starve all others of input- this will happen, for example, if a Motif program freezes while a menu is pulled down. (In a case like that, a user with an alternative means of access can kill the offending process remotely- but only experts can do that, so this case must still be counted as a severe failure of interprocess protection)
The only best way to fix this problem would require major changes to the X11 protocol- probably big enough to deserve a major version increase up to R7. It should be possible for applications to survive the shutdown/crash of the display server they are using, and attach to another one later. (Protocols like VNC and RDE allow that to a certain extent, as do some TTY consoles; X11 should too)
Cheating at a casino is circumventing the rules of the system in order to manipulate the outcome of said system.
Thats not what happened here! No rules were "circumvented". The rules were used to manipulate the outcome.
Timing the wheel had not been against the rules, so no rules were broken. In the future there will probably be a new rule added to forbid this behavior, but it didnt' exist yet.
Its the same thing as going to a bank with a gun and taking money out by force instead of using your ATM card.
That's why when I download albums from Kazaa, I make sure I don't delete the uploader's copy. That way it isn't theft, in any sense whatsoever. (Legal, English, and common usage).
The only way it could be theft is if you somehow deleted the copies from the original author, and then published it yourself. That's the only way "theft" can be applied to intellectual property
Ex: "She stole my song!" "He stole my invention!". Both phrases are understood to mean that one person claimed another's idea as her own.
I know some fansub groups still follow that decree.
I'm not saying they don't follow "the rule"; I'm saying that this rule is not why anime publishers tolerate fansubbers. They care much more about the fact that subs don't harm their dub market than they do about distribution "stopping" after licensing.
fansubbers weren't at fault here
Their actions are technically illegal, so they are at fault at least a little.
most still have a statement asking all who have their work to stop distribution.
"I'm giving this to you illegally right now, but don't you go giving it out illegally later"
If one criminal asks other people not to repeat his crime, that's not much of a mitigating factor.
If I write a song that turns out to be one of those timeless gems that is still loved decades from now, I will be grateful for the money it can provide for me and my family fifteen years out and beyond.
You'll be grateful that the corporation to which you sold the rights for a flat fee will get even more royalties? How generous of you... because that's the way the industry actually works in 99% of cases.
It seems like you are coming from a hypothetical position where artists retain the rights. That might be nice in theory, but the real world has proven itself to work differently.
Slashdot Mirror
That comment makes a spectacularly bad case. It provides no analysis to back up its wild claims. Approximately zero lines of the comment has to do with the paper, which it essentially mischaracterizes.
That paper makes a spectacularly bad case
It makes a fine case. The worst part is that it exaggerates the value of its own minor insight. The grandiose title harkens to the famous "Goto Considered Harmful", which in its time was a more insightful position.
Nobody should be surprised that globally correct choices cannot be decided with only locally correct data (for a non-greedy process, of course).
Moreover, the actual problems caused by suboptimal makefiles pales in comparison to what havoc goto can wreak. Anything wrong with makefiles can be solved by Moore's law (wait for the hardware to get faster, so you can do full rebuilds quickly). But spagetti code makes it more difficult for programmers to work with software, and there has been no observed exponential growth curve of human intelligence.
people write bad makefiles
That's a cop-out. The Makefile system has turned out to be too flexible for most needs. Because the build system relies on authors of individual make, the behavior of different Makefiles can be completely different (they're arbitrary programs, after all). That problem is analogous to the non-existent "package manager" on Microsoft Windows. Each Windows installer is an arbitrary program that might do anything, and whose actions cannot be reasoned about by software tools.
Furthermore, having one makefile in every directory is an almost assurewd way to produce bad makefiles.
which apply equally to recursive and monolithic ones.
Wrong. There is an inescapable difference in the performance (both speed and correctness). Recursive simply cannot compare with monolithic.
Note that "monolithic" doesn't necessarily mean the makefile is stored in only one file on disk. A collection of files assembled via include directives is equivalent to monolithic, but somewhat easier for revision control. Non-"make" build control processes, such as Ant or those provided with some IDEs, also share the advantages of monolithic makefiles.
The software industry has already demonstrated its support for RMCH, because all new "yet-another-better-than-make" projects take its ideas as unavoidable preconditions.
Actually I mentioned it in the first paragraph...
The point is that to a person unfamiliar with "compiler-intermediary" tools like distcc and ccache, the way to use them simultaneously is nonobvious.
Does the master host keep the cache, and farm out jobs on cache misses? Or does each box keep its own ccache, which is used to fulfill compilation jobs from the master? (Obviously, one of those options is drastically worse than the other)
Since you alluded to the possibility of distcc+ccache in the introduction, it is a disservice to your readers not to at least give a pointer to instructions on how to run them in tandem. At minimum, include this link. (And even better, add a disclaimed factoid on what your 6 minutes goes down to when ccache is in the mix)
They're called Pilot Licenses.
The need for a Pilot License to operate a car-sized plane is being removed in the US. The new Sport Pilot categorization will let you fly a single-seater (bigger than an "ultralight") with only a driver's license and 1 week of intense instruction.
And a quick survey of the accidents my geek friends have caused against the accidents my non-geek friends have caused would say the opposite.
So what does that prove? It's not as if geekiness has a positive correlation to intelligence!
I find excel a wonderful powerful intermediary program because of it's ease
Uh, powerful? Excel can't ever handle more than 65536 rows. It's easy for a 50k input file to exceed that limit.
Gnome does not violate any patents (for starters, I've never seen a patent that broad).
Then I guess you haven't seen many patents. Spend an hour browsing uspto.gov for software patents, and I trust you'll see enough to disgust you. It looks as if nearly every nontrivial program falls under 4-6 patents from random large corporations.
There's one patent, for example, which covers the GTK toolkit essential to all GNOME programs. GTK uses object orientation in a non-object-oriented language, therefore they are violating US Patent 5,446,902.
The account I read stated known uranium mines could meet our current energy demands for a few decades.
Find a better account. If all power plants went uranium today, we'd last for 50 years, assuming no technological advancement.
If a machine is ever invented to pull uranium from seawater, we'd have three times as much (but that'd cost energy to run, so effectively just twice as much)
Most importantly, uranium can be created from other elements. Thorium is far more common than uranium, but can probably be transformed to uranium by part of the reactor system.
Related tech changes could let uranium reactors become more than 20 times as efficient as they are today, meaning the power would last for 1000 years. Then we can collapse into a tribal apocalypse in 3004!
100% production to 0% production
The word "production" should never be used in reference to fossil fuels. The Middle East doesn't "produce" oil- it "extracts" it.
The inaccurate use of "produce" is one small way to keep the masses in denial about the obvious fact that oil is a non-renewable resource. Truthful speech will help the world mentally prepare to take the drastic steps necessary to move to a post-oil lifestyle.
(It also conceals the fact that nations like Iraq and Saudi Arabia don't and can't have an enconomy comprable to other nations with similar GNPs, as they merely sell off pre-existing assets)
For all of the people whining about the number of birds killed by power poles and cell phone towers, I encourage you to take a look at the number of birds killed by power-generating windmills.
Awesome! We get electricity and food!
Not only that, but it is a fallacy that the earth will ever "run out" of oil.
No, you're the one stating a fallacy. By oversimplfying to an incorrect definition of "run out", you have twisted the meaning of a claim. "Earth running out of oil" doesn't mean there are zero petroleum molecules left on the entire planet! It means we humans won't be able to acquire oil to use.
Consider a single modern automobile. As you drive it, petrol is used up. Does it ever run out of petrol? According to your argument, it never does, because there's always some miniscule amount left in the tank, even if it can't be reached for use.
So, it's win-win. Only drawback is
Funny, I thought the real drawback was that producing an organic oil takes more energy than you'll recieve from burning it...
Until we have lunar fusion plants beaming us energy on giant lasers, the production costs of artificial oil won't be worth it.
The Romans invented a steam engine, but didn't bother to develop it because they had slaves.
Or prehaps more importantly, because they had no coal. Steam engines are much more effective running on coal than wood. When steam power was reinvented in England, the abundant coal mines made it quickly useful for heavy industrial tasks.
(such as mining more coal!)
Yes, there are a lot more cars. That one reason why reducing automotive dependency is genuinely more important. Additional reasons:
Environmentalists and "conservationists" (heard of them?) want to see cars used much less... not just to reduce pollution, but also so that there still exists gasoline for sale in 50 years!
there is nothing wrong with using different metaphors for different tasks.
Oh yes there is! Consistency of presentation has great value for UI systems.
Your example is particularly bad... it introduces some secret magic number of files which, when reached, may totally change the appearance of folder screen. (That's a bad thing)
But also, you said "for different tasks". Copying a file from A to B is essentially the same task, whether it's remote or local. Yes, the computer may go through drastically different hardware+softare pathways to actually do the copy, but those details are something we should strive to conceal from the end user.
the computer can do all that, and the user can benefit.
FAR more importantly, I don't recommend that anyone attempt to "keep up" with other platforms that violate patents.
That's an unrealistic viewpoint. There are just TOO MANY software patents out there for a developer to worry about avoiding them until the patent-holder initiates action. ("Willful ignorance" is the official policy of the Linux Kernel developers, who've had some formal legal advice on the matter)
For example, both Debian and Red Hat are violating patents by shipping GNOME, so should they stop that too on the off-chance of an enforcement?
Spatial is a step backwards
Your experience with Gnome isn't enough evidence to to judge against "spatial" interfaces as a whole. As you noticed, the implementation is inconsistent- suggesting that the problem is not with "Spatial" itself, but that particular program.
However, pro-"Spatial" posters who jumped at you with "100% wrong" are also incorrect. In a deeper way, "Spatial" is truely a step backwards: because spatial filebrowsing is non-scalable.
It only works for small problems, where the total complexity is bounded. Back when the Mac was young and "Spatial" was in it's prime, users operated on single floppies or 100 megabyte HDs. The solutions that worked then become unbearably messy when a 100 gigabyte HD may have a quarter-million files.
And then there's networking. Considering that it may be useful to treat the drives of other computers or the whole internet with the same file-browser that handles your local data, and the quantity is just overwhelming.
Non-spatial file-views are the only way we can expect to view local and remote files through the same lense.
To make an analogy of a library: If you only have 20 books, then a card-catalog system is a waste of time. Just leave them out visible on a table, and let vistors find them "spatially". But with 20k books, the catalog is an important improvement, even though users can no longer retrieve volumes from "where I left it last time".
2. Windows servers can have multiple users logged in simultaneously, each with their own user interface. This capability is included in all Windows Server operating systems.
That is an invalid generalization. Windows Server operating systems are a subset of all Windows operating systems. A characteristic of the subset does not apply to the superset, so your comment doesn't reinforce the claim that "Windows is multiuser". If it were possible to get simultaneously logins with all current versions of Windows, then that would be significant.
(In reality, any OS can be considered multiuser if you install multiuser applications on it. Even MS-DOS had multiuser apps available.)
For stability, XFree is much nicer; if an app goes down or spins it's wheels looking for a resource, the rest of the system doesn't care one whit.
Untrue. It's still fairly easy for a program using XFree86 to freeze or crash the entire Xserver, killing any other process using it.
It is especially easy for one program to accidently starve all others of input- this will happen, for example, if a Motif program freezes while a menu is pulled down. (In a case like that, a user with an alternative means of access can kill the offending process remotely- but only experts can do that, so this case must still be counted as a severe failure of interprocess protection)
The only best way to fix this problem would require major changes to the X11 protocol- probably big enough to deserve a major version increase up to R7. It should be possible for applications to survive the shutdown/crash of the display server they are using, and attach to another one later. (Protocols like VNC and RDE allow that to a certain extent, as do some TTY consoles; X11 should too)
The rules of this particular guessing system say that you can't use outside equipment.
Do you actually know if the rules really say that, or are you just assuming?
Even so, the text of the rule is probably not as you stated. The phone/computer isn't "outside" equipment if it is inside with you, for example.
Or, if by "outside equipment" you meant supplied by the player, and not the casino, then nobody is allowed to wear eyeglasses...
Cheating at a casino is circumventing the rules of the system in order to manipulate the outcome of said system.
Thats not what happened here! No rules were "circumvented". The rules were used to manipulate the outcome.
Timing the wheel had not been against the rules, so no rules were broken. In the future there will probably be a new rule added to forbid this behavior, but it didnt' exist yet.
Its the same thing as going to a bank with a gun and taking money out by force instead of using your ATM card.
That's too stupid to even need a reply.
That's why when I download albums from Kazaa, I make sure I don't delete the uploader's copy. That way it isn't theft, in any sense whatsoever. (Legal, English, and common usage).
The only way it could be theft is if you somehow deleted the copies from the original author, and then published it yourself. That's the only way "theft" can be applied to intellectual property
Ex: "She stole my song!" "He stole my invention!". Both phrases are understood to mean that one person claimed another's idea as her own.
If it were, we wouldn't need new laws. Theft is already illegal.
So is copyright infringement. Therefore we don't really need a new law. Maybe just a little enforcement of existing laws...
I know some fansub groups still follow that decree.
I'm not saying they don't follow "the rule"; I'm saying that this rule is not why anime publishers tolerate fansubbers. They care much more about the fact that subs don't harm their dub market than they do about distribution "stopping" after licensing.
fansubbers weren't at fault here
Their actions are technically illegal, so they are at fault at least a little.
most still have a statement asking all who have their work to stop distribution.
"I'm giving this to you illegally right now, but don't you go giving it out illegally later"
If one criminal asks other people not to repeat his crime, that's not much of a mitigating factor.
If I write a song that turns out to be one of those timeless gems that is still loved decades from now, I will be grateful for the money it can provide for me and my family fifteen years out and beyond.
You'll be grateful that the corporation to which you sold the rights for a flat fee will get even more royalties? How generous of you... because that's the way the industry actually works in 99% of cases.
It seems like you are coming from a hypothetical position where artists retain the rights. That might be nice in theory, but the real world has proven itself to work differently.
What we are going to do is use Freenet
And then there will be a new law, and you will be arrested simply for possessing the Freenet software...