Shipping IE with Windows wasn't what violated anti-trust laws. It was their manipulation of the markets surrounding that that was. I read the judge's findings of fact back when the lawsuit was taking place; I remember the details clearly. MS didn't let OEMs remove IE (naturally, it's part of the OS) but they also didn't let OEMs install competing products. That, and other related market manipulations involving the price of the Windows OEM license, was what violated the law.
The browser and the HTML controls are a fundamental feature of a complete operating environment. If the government can step in and say "you need to take X out of your OS because someone else might want to sell and X", that does not actually benefit the customers whose software, which used that X, no longer works. Consider notepad: it's such an important program that Windows won't even let you replace it. That's because, for the decades that it's been there, there are hundreds of programs out there which have come to rely on it. If you take it away, those programs will malfunction. Even if you install a different text editor. The same is true for IE.
All that MS has to do to satisfy antitrust violations is to provide a way for people to replace certain IE functionality with equivalent COM objects, or to allow people to install other browsers. The applet which allows you to specify system-wide default browsers, media players, etc, is the right idea. Getting rid of the MSHTML control or iexplorer.exe is not.
I guess nobody cares about the countless applications which depend on installed apps like notepad or iexplorer.exe to get stuff done? Sure, those apps may be badly coded, but they exist and people want to continue running them.
Sure, a benchmark can be misunderstood or misinterpreted and vendors often count on this to work in their favour. But that doesn't negate the fact that the filesystem is 100x faster at something, and if your workload depends on setting extended attributes (to use your example) a lot, that may matter significantly.
So is totally unreasonable to look at existing workloads that perform badly, then create a new filesystem optimized for those workloads, then benchmark against those workloads? Maybe the developer doesn't know how YOU will use the filesystem but if you don't know for what kinds of work it was optimized, you might be using the wrong tool for your new task.
I consider that an implementation detail that should be taken care of by the client library. There's no reason that it can't batch up all the preparing + binding and send it all at once the first time you call execute(). In any case, given the absurdity of trying to sanitize every single input field (let's face it: most programmers aren't up to the task) I think using Prepared Statements is well worth any performance penalty in this case.
You need to keep in mind the difference between a Prepared Statement and a Stored Procedure.
A Stored Procedure is a function stored in the database that you call from the application. There are pros and cons, which I won't go into here. Personally I don't like them but I can see why some people love them.
A Prepared Statement, however, is the most useful tool you can use to protect yourself from SQL injection and every program should use them all the time. If there were a way to get rid of NON-prepared statements I think that'd be the right thing to do but I'd never use a DB that didn't support prepared statements. Let me illustrate the difference (Java-like pseudo-code):
Connection con = getConnection(); Statement stmt = con.createStatement("Select * from users where username = '" + username + "' and password = '" + password + "'); ResultSet rs = stmt.executeQuery();
PreparedStatement pstmt = con.prepareStatement("Select * from users where username = ? and password = ?");// bind parameters pstmt.setString(1, username); pstmt.setString(2, password); ResultSet rs = pstmt.executeQuery();
The PreparedStatement example looks like more code to write, and it is (But you can write utility functions to simplify this if you want). But there are two advantages: 1. You can re-use the PreparedStatement if you need to run the query more than once with different parameters and this saves processing. 2. The bound parameters are automatically converted internally to parameters so that the SQL doesn't have to parse the parameters themselves. This protects you from SQL injection. If the query above had been used in the application's login module, anyone could log in if they typed in the administrator's username and the password ' OR 1 = 1; --
The reason is that in the first example the password contains SQL code. The SQL parser can't tell the difference between your parameter (the password) and the code because you passed it in as all one string. In the second case the parser sees that there is a variable and binds the value to that variable during execution of the statement. The variable isn't parsed as code.
Someone reading this is probably thinking "Just escape the parameters manually!", which helps, but by always using prepared statements and binding parameters you will never miss a parameter or have to worry about bugs in the escaping routine (PHP's mysql module has had several bugs in those routines).
I can't stress this benefit of prepared statements enough. It is so critical that we don't hire people at my company who don't understand this problem.
This already happens to me on my landline. Voicemails appear from nowhere and they're for ads. Luckily, when listening to the message I can hit a key to skip through to the end for quick deletion. Funny, I just noticed that the key sequence for 'begin listening, skip to end, delete' is 1-3-3-7.
not only that but in Ontario a lot of medical roles are being pushed to pharmacists. But we're still talking about licensed professionals; even Telehealth is staffed by nurses.
Heck, I've had problems where smoke is coming into my condo or apt and the smoker in question is down the hall or on a different floor. There's no way to ensure where the air flows. I've always wanted a condominium where the whole building is smoke-free. But I don't favour a world-wide ban, I think people should be allowed to smoke in areas where they can't disturb other people. If your smoking isn't bothering anyone, go nuts. But your smoking shouldn't intrude on my apartment.
"Competing products", or else products that didn't work well in Vista either, only Microsoft didn't find out just how bad it was and is only now updating the blacklist? I mean, some products just do bad things to the OS, and they just won't work in Vista. If MS didn't test this product or didn't discover how badly the product breaks Vista, they might not have blacklisted the product when Vista was released. Claiming that the products don't work because of new code in SP1 is inaccurate, I think.
The thing is, copyright is already "lifetime + 70" for the composers of the piece. The royalties in question in the article are for PERFORMERS. Now, performing music is hard, but so is surgery, and we don't pay surgeons once they retire.
You might not be able to use weak references since they introduce (at least in Java) a layer of indirection. For example, an addListener method usually takes an interface of some kind of Listener, not a WeakReference (to a listener).
Now, if you have control of the implementation of the object who accepts Listeners you can store them internally in a weak collection, which allows them to be garbage-collected. This would work but may not be what the programmer intends. Actually in a language like Java I'd hazard that usually the programmer wouldn't want that at all: consider an application that listens to UI events. As a programmer I want to be able to stick listeners wherever they are needed and leave them there permanently. If I don't need a pointer to the object, I don't want to keep it around, and thus may not have a reference to the listener EXCEPT in the event-management collection. That's the advantage of GC languages: as soon as the object which creates those events (say, a dialog box) goes away, the objects it refers to have one fewer pointer and may be eligible for GC.
Anyway, lots of code has issues like this: we had a problem at my work where an Apache taglib was caching some compilation in a cache that would grow for ever. It was a simple code fix to solve that problem, but there was no way for us to even SEE the problem until we ran our application under load in a profiler. Fun fun fun.
Autoboxing isn't as big a problem as autounboxing. void doSomething(Object a) {}//... int i = 0; doSomething(i);
if doSomething takes an object, you're ok, there's just a hidden memory cost. Auto-unboxing is worse: Integer i = null; i = i + 1;// hidden NullPointerException
This is where your code has mysterious problems, and when you're reading a line of code and you have no idea why there's an NPE there...
Obviously it's the guys with the guns who are paid to secure the premises who get to determine what looks like an IED. That is what they're paid to do, after all.
Having a more variable ecosystem for operating systems would make viruses spread more slowly but it wouldn't eliminate the problem and would increase all other costs: costs of software development, costs of administration, costs of training, costs of inventory management, etc.
In the end abstraction layers would form where viruses could still spread. If everyone had a unique OS, but ran a web browser that supported Javascript, then people would develop Javascript viruses.
So you're saying that most parents will be happy that the filter is there if they're not using it, and don't believe they are using it? No sane person would ascribe the same benefit to "I have a filter and know I am not using it" versus "I have a filter and am using it". The original comment was saying that the ICON was enough to satisfy most parents, implying that they did not actually care if the filtering was happening or not. I am 100% sure that that is completely false, which is why my comment was addressed toward the case where the parents believe they have a filter WHICH IS ON AND FILTERING, but has actually been disabled: these parents will feel good that the filter is working but their trust is misplaced, which is a problem they are not equipped to deal with. I still maintain that HAVING a filter versus USING a filter are completely different and nobody will feel that merely having it, but not using it, is in any way equivalent, unless they don't actually feel they need the filter anyway.
It's possible you were using too many ISA devices in your 486. I had a DX4-100 as a server for a while and it wasn't able to transfer files and play music at the same time until I changed all the devices to PCI, and then it worked fine.
The truth is most parents are not technically competent to understand how the filtering works, and have no choice but to trust that icon = filter. This is totally different from your other examples, such as buying a cellphone for the kids and never calling them, or never tracking them with the GPS feature. Has it occurred to you that tracking your kids by GPS might be something only used in an emergency? I wouldn't have wanted my parents to monitor my position 24/7 but if I didn't show up for dinner it would be useful for them to know where I was, especially if I didn't answer the phone. That kind of information could be invaluable if I'd been in accident.
Your other example, buying a V-Chip and never setting it up, or buying anti-virus software and never using it, are different from using a v-chip or A/V and trusting them to work, when in fact your v-chip or A/V has been disabled and replaced with a decoy. How is a non-technical person supposed to know the difference? If the v-chip says "running" and the parent doesn't try to watch porn, they'll never see that it's busted.
Face it: the majority of the world is not technical and never will be. Many of those people are non-technical because they are idiots, but the rest just aren't inclined to learn it, because they have too many other responsibilities. I'm very technical and have learned a great deal about computers and electronics but know very little about cars, does that make me an idiot? Does that mean that if I buy a car and the fuel gauge doesn't work I'm somehow a fool for trusting it? Of course not.
My original post lumped all the "humanities" under a label called "arts" so I think that may have confused things; I wasn't referring just to "artists" but also all the other subjects typically taught at a faculty of arts (i.e. Language, Literature, Philosophy, Drama, Music, History, etc). These subjects can give you insight into certain things, but do not prepare you for specific jobs. Someone who has studied linguistics and psychology (but is not a psychologist) will understand human behaviour and will be able to apply that to certain tasks, but that doesn't mean they can do just anything, nor that their training will be useful for just any job. Engineering, however, trains you for specific tasks and specific jobs. Of course, you can take your engineering knowledge and use it for other purposes, jobs that are not typical of engineers, but my basic point stands: and engineer is trained for a specific task while a liberal arts major is trained for no specific task.
As for your comment about an artist who knows programing/CAD, well, that's great, but I think we're talking about a different kind of "art". But learning CAD is, I'd say, not something that belongs in a traditional liberal arts degree anyway; it's more the kind of thing you'd learn in a vocational college or art school. It's a specific skill that an artist uses for specific tasks, but is not something you'd learn while studying the classic masterpieces or art history.
What I find surprising is that some professors still don't understand that Engineering is not Arts, and its goals and values are fundamentally different. An arts education is an abstract thing, a more classical education where you learn history and discuss concepts and ideas. When you graduate you have nothing tangible that you can use for any particular job but are expected to be intelligent enough to succeed at something if you work hard. An engineering education is meant to train you to think, but also to train you in specialized tools that you will need to perform very specialized tasks. You can't build a bridge (safely) unless you understand physics and materials science and weather and economics. You can't build a car without understanding electricity and fluid dynamics and chemistry and physics. These and other engineering skills are not things most people can just pick up as they go along, and hence we have specialized schools to teach them. People study arts because they want to learn, people study engineering because they want to be engineers. It's not surprising that an engineering school has completely different needs than an arts school, and thus different tuition.
Copyright law, at least in Canada (I have read the Copyright Act, but IANAL) specifically includes things like making guitar tablature as making a copy. Copyright doesn't depend on the means of reproduction; even if the new work is different but very similar to the original work, and is derived from the original work, it doesn't excuse the copyright obligations of the "copier". If you read a novel, and write it out by hand, you are not allowed to distribute that copy, even if you make spelling mistakes or re-word a few sentences. Heck, you are not even allowed to translate a work into another language. You are not allowed to make a movie out of a copyrighted book nor sing a song with the same tune as another song, even if you change the lyrics. To my knowledge these basic rules are in all copyright laws passed in any countries that signed the Berne Convention.
Don't confuse things too much though, because the derived work may be subject to the "copier's" copyright as well; consider a translation of one book into another language. The author of the book owns the copyright for that book, but not the copyright for the translated book (assuming it was translated without authorization of the author). The copyright for the translation rests with the translator, however, since it is derived from a copyrighted work, the translator can not distribute it without permission from the author. The author does not have permission to dictate when the translation will be distributed; the author can only dictate when it will NOT be distributed, until the copyright of the original work expires. Similarly, the authors of the guitar tablature can prevent others from copying their work, however the artists who wrote the songs in question (or, whoever owns the copyright) can prevent the distribution of tab.
Note: This post is meant to explain copyright law. It is not meant as an endorsement or condemnation of this law.
Why? What the hell gives a child the right to earn a living from his parents' work? If you want to have a living, you should have to do your own work and earn your money, not sit back and expect money to roll into your pockets because of someone else's hard work. Why should people expect to get money from work they had nothing to do with producing? What's fair about that?
The argument isn't that a child has the RIGHT to earn money from their parents' work, but rather the inverse: A parent strives to provide for their children, and thus an artistic parent would strive to create more valuable art in order to provide more revenue from that art to his/her children.
Note: I'm not saying I agree with this reasoning, but when you look at it from the perspective of the parent, there is some sense to it, as a reward for the artist.
Slashdot Mirror
Shipping IE with Windows wasn't what violated anti-trust laws. It was their manipulation of the markets surrounding that that was. I read the judge's findings of fact back when the lawsuit was taking place; I remember the details clearly. MS didn't let OEMs remove IE (naturally, it's part of the OS) but they also didn't let OEMs install competing products. That, and other related market manipulations involving the price of the Windows OEM license, was what violated the law.
The browser and the HTML controls are a fundamental feature of a complete operating environment. If the government can step in and say "you need to take X out of your OS because someone else might want to sell and X", that does not actually benefit the customers whose software, which used that X, no longer works. Consider notepad: it's such an important program that Windows won't even let you replace it. That's because, for the decades that it's been there, there are hundreds of programs out there which have come to rely on it. If you take it away, those programs will malfunction. Even if you install a different text editor. The same is true for IE.
All that MS has to do to satisfy antitrust violations is to provide a way for people to replace certain IE functionality with equivalent COM objects, or to allow people to install other browsers. The applet which allows you to specify system-wide default browsers, media players, etc, is the right idea. Getting rid of the MSHTML control or iexplorer.exe is not.
I guess nobody cares about the countless applications which depend on installed apps like notepad or iexplorer.exe to get stuff done? Sure, those apps may be badly coded, but they exist and people want to continue running them.
Sure, a benchmark can be misunderstood or misinterpreted and vendors often count on this to work in their favour. But that doesn't negate the fact that the filesystem is 100x faster at something, and if your workload depends on setting extended attributes (to use your example) a lot, that may matter significantly.
So is totally unreasonable to look at existing workloads that perform badly, then create a new filesystem optimized for those workloads, then benchmark against those workloads? Maybe the developer doesn't know how YOU will use the filesystem but if you don't know for what kinds of work it was optimized, you might be using the wrong tool for your new task.
you're being sarcastic but they have USB record players now.
I consider that an implementation detail that should be taken care of by the client library. There's no reason that it can't batch up all the preparing + binding and send it all at once the first time you call execute(). In any case, given the absurdity of trying to sanitize every single input field (let's face it: most programmers aren't up to the task) I think using Prepared Statements is well worth any performance penalty in this case.
You need to keep in mind the difference between a Prepared Statement and a Stored Procedure.
A Stored Procedure is a function stored in the database that you call from the application. There are pros and cons, which I won't go into here. Personally I don't like them but I can see why some people love them.
A Prepared Statement, however, is the most useful tool you can use to protect yourself from SQL injection and every program should use them all the time. If there were a way to get rid of NON-prepared statements I think that'd be the right thing to do but I'd never use a DB that didn't support prepared statements. Let me illustrate the difference (Java-like pseudo-code):
Connection con = getConnection();
Statement stmt = con.createStatement("Select * from users where username = '" + username + "' and password = '" + password + "');
ResultSet rs = stmt.executeQuery();
PreparedStatement pstmt = con.prepareStatement("Select * from users where username = ? and password = ?"); // bind parameters
pstmt.setString(1, username);
pstmt.setString(2, password);
ResultSet rs = pstmt.executeQuery();
The PreparedStatement example looks like more code to write, and it is (But you can write utility functions to simplify this if you want).
But there are two advantages:
1. You can re-use the PreparedStatement if you need to run the query more than once with different parameters and this saves processing.
2. The bound parameters are automatically converted internally to parameters so that the SQL doesn't have to parse the parameters themselves. This protects you from SQL injection. If the query above had been used in the application's login module, anyone could log in if they typed in the administrator's username and the password ' OR 1 = 1; --
The reason is that in the first example the password contains SQL code. The SQL parser can't tell the difference between your parameter (the password) and the code because you passed it in as all one string. In the second case the parser sees that there is a variable and binds the value to that variable during execution of the statement. The variable isn't parsed as code.
Someone reading this is probably thinking "Just escape the parameters manually!", which helps, but by always using prepared statements and binding parameters you will never miss a parameter or have to worry about bugs in the escaping routine (PHP's mysql module has had several bugs in those routines).
I can't stress this benefit of prepared statements enough. It is so critical that we don't hire people at my company who don't understand this problem.
This already happens to me on my landline. Voicemails appear from nowhere and they're for ads. Luckily, when listening to the message I can hit a key to skip through to the end for quick deletion. Funny, I just noticed that the key sequence for 'begin listening, skip to end, delete' is 1-3-3-7.
not only that but in Ontario a lot of medical roles are being pushed to pharmacists. But we're still talking about licensed professionals; even Telehealth is staffed by nurses.
Heck, I've had problems where smoke is coming into my condo or apt and the smoker in question is down the hall or on a different floor. There's no way to ensure where the air flows. I've always wanted a condominium where the whole building is smoke-free. But I don't favour a world-wide ban, I think people should be allowed to smoke in areas where they can't disturb other people. If your smoking isn't bothering anyone, go nuts. But your smoking shouldn't intrude on my apartment.
"Competing products", or else products that didn't work well in Vista either, only Microsoft didn't find out just how bad it was and is only now updating the blacklist? I mean, some products just do bad things to the OS, and they just won't work in Vista. If MS didn't test this product or didn't discover how badly the product breaks Vista, they might not have blacklisted the product when Vista was released. Claiming that the products don't work because of new code in SP1 is inaccurate, I think.
The thing is, copyright is already "lifetime + 70" for the composers of the piece. The royalties in question in the article are for PERFORMERS. Now, performing music is hard, but so is surgery, and we don't pay surgeons once they retire.
Come on, are you serious? And if the IPv4 fails, they should try to find the site using IPX or Arpanet protocols?
so you can't do the following:
// not found
Integer i = getIdByName(name);
if (i == null) {
}
or am I misunderstanding what you're saying?
As far as I'm concerned the object wrappers for primitives are useful because they CAN be null, but this makes autounboxing more dangerous.
You might not be able to use weak references since they introduce (at least in Java) a layer of indirection. For example, an addListener method usually takes an interface of some kind of Listener, not a WeakReference (to a listener).
Now, if you have control of the implementation of the object who accepts Listeners you can store them internally in a weak collection, which allows them to be garbage-collected. This would work but may not be what the programmer intends. Actually in a language like Java I'd hazard that usually the programmer wouldn't want that at all: consider an application that listens to UI events. As a programmer I want to be able to stick listeners wherever they are needed and leave them there permanently. If I don't need a pointer to the object, I don't want to keep it around, and thus may not have a reference to the listener EXCEPT in the event-management collection. That's the advantage of GC languages: as soon as the object which creates those events (say, a dialog box) goes away, the objects it refers to have one fewer pointer and may be eligible for GC.
Anyway, lots of code has issues like this: we had a problem at my work where an Apache taglib was caching some compilation in a cache that would grow for ever. It was a simple code fix to solve that problem, but there was no way for us to even SEE the problem until we ran our application under load in a profiler. Fun fun fun.
Autoboxing isn't as big a problem as autounboxing.
// ...
// hidden NullPointerException
void doSomething(Object a) {}
int i = 0;
doSomething(i);
if doSomething takes an object, you're ok, there's just a hidden memory cost.
Auto-unboxing is worse:
Integer i = null;
i = i + 1;
This is where your code has mysterious problems, and when you're reading a line of code and you have no idea why there's an NPE there...
Obviously it's the guys with the guns who are paid to secure the premises who get to determine what looks like an IED. That is what they're paid to do, after all.
Having a more variable ecosystem for operating systems would make viruses spread more slowly but it wouldn't eliminate the problem and would increase all other costs: costs of software development, costs of administration, costs of training, costs of inventory management, etc.
In the end abstraction layers would form where viruses could still spread. If everyone had a unique OS, but ran a web browser that supported Javascript, then people would develop Javascript viruses.
So you're saying that most parents will be happy that the filter is there if they're not using it, and don't believe they are using it? No sane person would ascribe the same benefit to "I have a filter and know I am not using it" versus "I have a filter and am using it". The original comment was saying that the ICON was enough to satisfy most parents, implying that they did not actually care if the filtering was happening or not. I am 100% sure that that is completely false, which is why my comment was addressed toward the case where the parents believe they have a filter WHICH IS ON AND FILTERING, but has actually been disabled: these parents will feel good that the filter is working but their trust is misplaced, which is a problem they are not equipped to deal with. I still maintain that HAVING a filter versus USING a filter are completely different and nobody will feel that merely having it, but not using it, is in any way equivalent, unless they don't actually feel they need the filter anyway.
It's possible you were using too many ISA devices in your 486. I had a DX4-100 as a server for a while and it wasn't able to transfer files and play music at the same time until I changed all the devices to PCI, and then it worked fine.
The truth is most parents are not technically competent to understand how the filtering works, and have no choice but to trust that icon = filter. This is totally different from your other examples, such as buying a cellphone for the kids and never calling them, or never tracking them with the GPS feature. Has it occurred to you that tracking your kids by GPS might be something only used in an emergency? I wouldn't have wanted my parents to monitor my position 24/7 but if I didn't show up for dinner it would be useful for them to know where I was, especially if I didn't answer the phone. That kind of information could be invaluable if I'd been in accident.
Your other example, buying a V-Chip and never setting it up, or buying anti-virus software and never using it, are different from using a v-chip or A/V and trusting them to work, when in fact your v-chip or A/V has been disabled and replaced with a decoy. How is a non-technical person supposed to know the difference? If the v-chip says "running" and the parent doesn't try to watch porn, they'll never see that it's busted.
Face it: the majority of the world is not technical and never will be. Many of those people are non-technical because they are idiots, but the rest just aren't inclined to learn it, because they have too many other responsibilities. I'm very technical and have learned a great deal about computers and electronics but know very little about cars, does that make me an idiot? Does that mean that if I buy a car and the fuel gauge doesn't work I'm somehow a fool for trusting it? Of course not.
My original post lumped all the "humanities" under a label called "arts" so I think that may have confused things; I wasn't referring just to "artists" but also all the other subjects typically taught at a faculty of arts (i.e. Language, Literature, Philosophy, Drama, Music, History, etc). These subjects can give you insight into certain things, but do not prepare you for specific jobs. Someone who has studied linguistics and psychology (but is not a psychologist) will understand human behaviour and will be able to apply that to certain tasks, but that doesn't mean they can do just anything, nor that their training will be useful for just any job. Engineering, however, trains you for specific tasks and specific jobs. Of course, you can take your engineering knowledge and use it for other purposes, jobs that are not typical of engineers, but my basic point stands: and engineer is trained for a specific task while a liberal arts major is trained for no specific task.
As for your comment about an artist who knows programing/CAD, well, that's great, but I think we're talking about a different kind of "art". But learning CAD is, I'd say, not something that belongs in a traditional liberal arts degree anyway; it's more the kind of thing you'd learn in a vocational college or art school. It's a specific skill that an artist uses for specific tasks, but is not something you'd learn while studying the classic masterpieces or art history.
What I find surprising is that some professors still don't understand that Engineering is not Arts, and its goals and values are fundamentally different. An arts education is an abstract thing, a more classical education where you learn history and discuss concepts and ideas. When you graduate you have nothing tangible that you can use for any particular job but are expected to be intelligent enough to succeed at something if you work hard. An engineering education is meant to train you to think, but also to train you in specialized tools that you will need to perform very specialized tasks. You can't build a bridge (safely) unless you understand physics and materials science and weather and economics. You can't build a car without understanding electricity and fluid dynamics and chemistry and physics. These and other engineering skills are not things most people can just pick up as they go along, and hence we have specialized schools to teach them. People study arts because they want to learn, people study engineering because they want to be engineers. It's not surprising that an engineering school has completely different needs than an arts school, and thus different tuition.
Copyright law, at least in Canada (I have read the Copyright Act, but IANAL) specifically includes things like making guitar tablature as making a copy. Copyright doesn't depend on the means of reproduction; even if the new work is different but very similar to the original work, and is derived from the original work, it doesn't excuse the copyright obligations of the "copier". If you read a novel, and write it out by hand, you are not allowed to distribute that copy, even if you make spelling mistakes or re-word a few sentences. Heck, you are not even allowed to translate a work into another language. You are not allowed to make a movie out of a copyrighted book nor sing a song with the same tune as another song, even if you change the lyrics. To my knowledge these basic rules are in all copyright laws passed in any countries that signed the Berne Convention.
Don't confuse things too much though, because the derived work may be subject to the "copier's" copyright as well; consider a translation of one book into another language. The author of the book owns the copyright for that book, but not the copyright for the translated book (assuming it was translated without authorization of the author). The copyright for the translation rests with the translator, however, since it is derived from a copyrighted work, the translator can not distribute it without permission from the author. The author does not have permission to dictate when the translation will be distributed; the author can only dictate when it will NOT be distributed, until the copyright of the original work expires. Similarly, the authors of the guitar tablature can prevent others from copying their work, however the artists who wrote the songs in question (or, whoever owns the copyright) can prevent the distribution of tab.
Note: This post is meant to explain copyright law. It is not meant as an endorsement or condemnation of this law.
The argument isn't that a child has the RIGHT to earn money from their parents' work, but rather the inverse: A parent strives to provide for their children, and thus an artistic parent would strive to create more valuable art in order to provide more revenue from that art to his/her children.
Note: I'm not saying I agree with this reasoning, but when you look at it from the perspective of the parent, there is some sense to it, as a reward for the artist.