In this discussion, it is important to remember that there are two issues here that need to be separated before you start ranting and raving.
issue 1. the ability for a court to request that an internet service provider (or some other intermediate or secondary entity) provide identifying information about alleged infringers of copyright protected material [in this case, verizon are the secondary parties].
issue 2. an entity (the copyright holder, or party with rights in the copyright works) with information that identifies a copyright infringer making the request in (1) [in this case, RIAA].
You can disagree with that tactics of (2) [i.e. the overbearing strong-arms], but you can't disagree with the issue in (1) where the court decides that based upon information provided by (2), that there is prima facia case for copyright infringement, and there is sufficient information to be able to identify the infringing party.
The court has to exercise its judgement (and it doesn't always get it right, but typically it's not too gung-ho) to determine whether (2)'s evidence looks worthy.
The entity in (1) is technically responsible for secondary infringement when it comes to the copyright material - but under safe harbour provisions, it is indemnified until it is made aware of infringement, and takes actions to deal with infringement. This safe harbour concept existed wrt. copyright and intellectual property before DMCA and its explicit safe harbour provisions existed.
If (1) is made aware that it is party to secondary infringement, and faced with strong evidence that this is the case, and (1) takes no action, then potentially, (1) becomes liable as a party to the infringement as it would then have "sufficient" knowledge that infrigement is taking place, yet chose not to deal with it.
I'm sorry if you think that freedom of speech allows (1) to turn a blind eye to infringement of copyright, but if you do think this, you just don't understand how things work properly. (1) has some protection against things that it is not aware of, but it doesn't have absolute protection, that would just render it impossible to enforce many laws where there is evidence of an illegal act taking place, but a secondary party needs to provide information to help narrow down the entity.
Most demos/intros/scene productions are developed by self-taught 'coders', involving:
- reverse engineering of existing demos / intros / etc;
- gradual mastery of production through multiple repeated attempts;
- reference books (algorithms, language reference, machine reference);
- sometimes brain-smashing with other coders;
One of the key features of a good demo/intro is the way that it pushes the machine somehow, by particular use of machine features (undocumented hardware features, novel algorithms [self modifying code, runtime code production, novel graphics algorithms, etc]). Basically, the better demos cause you to marvel in wonder somehow.
There's also a need for an art/design element as well - good composition, structuring, arrangement of music, graphics, etc. Often you get this from a collaboration of a group (coder, grafician, musician, etc) more than one lone coder.
I should know, I used to produce demos/intros in the C64 scene many years ago. I suspect the same culture lives on into PC/playstation/etc. The difference is the level of power available, and perhaps being able to use higher level tools.
Anyone in the scene would treat so called 'games' or 'demo programming' books with horror and run a mile. Typically such books are aimed purely at trapping wannabe demo makers / coders and aren't really that useful.
The advice is: look at existing demos/intros, start making your own, your first productions will possibly be not very good: improve, try again. If you are clever/intelligent/capable, then within a few iterations you'll start producing world class. Timeframe: 2 years.
Most of this discussion seems to be about interactive debugging tools, but as an individual concerned with mission critical telecommunications software where an outage can take out customer private networks, I tend to find less need for interactive debugging, and greater need for post-mortem diagnostic analysis that results from the following:
- faults generated in house system / integration testing
- faults generated in house automated unit / component testing
- faults generated in house automated system / scalability / performance testing
I need to isolate sometimes highly obscure run-time failures and discover what went wrong, then resolve the issue, which I do with:
- high levels of run-time instrumentation using (a) method / object / runtime c++ trace style classes, (b) trace back mechanisms for exception handling and, (c) assertion handling and (d) run-time verification mechanisms; all of which generate output to debug logs (sometimes when returned to support, these logs are multi-gigabyte in size, fortunately our development workstations are very high spec)
- post-mortem analysis scripts to interpret the contents of debug logs and look for faults, inconsistencies and other issues
- application level mechanisms to allow testing, deployment and other experts to enable run-time debug instrumentation (if it were enabled all the time, it would constitute considerable performance loss) sometimes at the direction of developers or deployment / field support personnel, and sometimes these personnel don't have access to machines where the components are installed (because the components are distributed CORBA components, and these personnel have access to host / user interfaces, but not to components in a silo in another country)
The problem is that we've had to design all of this from scratch: (a) general purpose c++ based debugging / tracing modules with command line / run time configuration options, (b) tools to stimulate the debugging facilities to do things [set / change debug trace levels / activation tags / identifiers], (c) tools to capture / wrap up and return trace logs back to support, including capturing host information (processes, memory, installed modules, environment, configuration) and other debugging items (debug stack traces, core dumps) and version information (component version, etc), (d) tools to analyse / work with / process logs for developers, (e) work instructions / process / documentation to educate developers, deployment experts and others about the use of these facilities, (f) make sure that there's a balance between getting the right level of detail, yet avoiding gigabytes of detailed code / method level information
Typically, once I have a debug log returned to me (as I am developer), I need to look at what was going on, and try to reproduce the fault with a unit test case, then inspect the component for faults of a similar type, and correct those with appropriate unit tests as well, then verify regression test for the component, make changes to multiple development branches, and wait for the scheduling of scalability / system / automated testing to ensure no other significant side effects, then safely know that the next release will have corrections.
We shouldn't have had to develop all of this in house: there should be standards for this. Other companies that I have worked with have the same adhoc construction of debugging facilities - for these situations were you need to analysis a running system, or obtain post-mortem results.
Interative debugging dwindles in comparison: unless you are working with obscure hardware, or related sorts of embedded systems, I think that an excessive need to use interative debugging says more about the lack of design / defensive coding / other engineering approaches to reliability of the constructed software. Interative debugging consumes about 10% of my debugging efforts (not including time spend on unit / component / system test design).
What irks me is that people with a degree assume that they are more talented and educated than people who are self educated. In many cases, the only difference between someone with a degree and someone without one is that piece of paper.
Hey, I hope you aren't suggesting that is what I meant: it works both ways, there are many talented and educated people that didn't go to university. But, at least university uses the wisdom of many many years of experience about learning processes and the brains trust of very good people. And lets talk about _averages_ here. We're talking that _on average_ people do better if they go to university than if they don't. There are always exceptions, and "stars" (and equally, "dropouts"), but speaking statistically, unless you are gifted, a genius, or have some special qualities about you that but you above the league in the first place, then the _chances are_ you're going to do better with a university education.
When you're 35 or 40 it's nothing but a worthless piece of paper when you have 15-20 years of experience behind you.
Not entirely true: it's value does decrease over time. This is why I say that you need to make use of your education: in 15 years time, mmany of your college educated peers are going to be in good positions having made a career, so if you're wise and have retained your connections, then you're making some use of your education more than just a piece of paper. But, I'm 10 years out of university, and I still draw upon my education.
Not entirely true. For instance, in engineering, you learn a lot of junk in university about forces, waves, systems, etc. Most of the actual content you learn turns out to be useless in your career (in my experience), but the underlying principles learnt (logical thinking, systems perspective, etc) are invaluable. In my years in industry, I see that non-university people learn all the technical skills, do their job well (and in many cases better) than the university graduates, but I consistently see the quality of approach / process in the university graduates that isn't in the non-graduates. I agree that you need _both_ work experience and university - many university graduates with no experience are not very practical or useful. The people that do extremely well are the ones that have a combination of both: they have the only the job work smarts and street smarts, and the get in there and do it approach, but they also have the methodical, systems, disciplined theorical balance that really only comes from a good university education.
You need to wait a few more years, and perhaps you need to more actively make value from your education. By the sounds of it, you're expecting the rest of the world to pay you back - life just doesn't work that way.
Take interest in professional associations, ensure that in your work assignments you make use of the skills you learnt (analytical, critical thinking, good judgement), retain connections with your peers in the industry from university, etc. Make better use of your education.
Studies show that after 5-10 years, university educated students catch up and surpass those that didn't go to university. University pays off eventually, but you have to make it work for you.
Slashdot Mirror
In this discussion, it is important to remember that there are two issues here that need to be separated before you start ranting and raving.
issue 1. the ability for a court to request that an internet service provider (or some other intermediate or secondary entity) provide identifying information about alleged infringers of copyright protected material [in this case, verizon are the secondary parties].
issue 2. an entity (the copyright holder, or party with rights in the copyright works) with information that identifies a copyright infringer making the request in (1) [in this case, RIAA].
You can disagree with that tactics of (2) [i.e. the overbearing strong-arms], but you can't disagree with the issue in (1) where the court decides that based upon information provided by (2), that there is prima facia case for copyright infringement, and there is sufficient information to be able to identify the infringing party.
The court has to exercise its judgement (and it doesn't always get it right, but typically it's not too gung-ho) to determine whether (2)'s evidence looks worthy.
The entity in (1) is technically responsible for secondary infringement when it comes to the copyright material - but under safe harbour provisions, it is indemnified until it is made aware of infringement, and takes actions to deal with infringement. This safe harbour concept existed wrt. copyright and intellectual property before DMCA and its explicit safe harbour provisions existed.
If (1) is made aware that it is party to secondary infringement, and faced with strong evidence that this is the case, and (1) takes no action, then potentially, (1) becomes liable as a party to the infringement as it would then have "sufficient" knowledge that infrigement is taking place, yet chose not to deal with it.
I'm sorry if you think that freedom of speech allows (1) to turn a blind eye to infringement of copyright, but if you do think this, you just don't understand how things work properly. (1) has some protection against things that it is not aware of, but it doesn't have absolute protection, that would just render it impossible to enforce many laws where there is evidence of an illegal act taking place, but a secondary party needs to provide information to help narrow down the entity.
Most demos/intros/scene productions are developed by self-taught 'coders', involving: - reverse engineering of existing demos / intros / etc; - gradual mastery of production through multiple repeated attempts; - reference books (algorithms, language reference, machine reference); - sometimes brain-smashing with other coders; One of the key features of a good demo/intro is the way that it pushes the machine somehow, by particular use of machine features (undocumented hardware features, novel algorithms [self modifying code, runtime code production, novel graphics algorithms, etc]). Basically, the better demos cause you to marvel in wonder somehow. There's also a need for an art/design element as well - good composition, structuring, arrangement of music, graphics, etc. Often you get this from a collaboration of a group (coder, grafician, musician, etc) more than one lone coder. I should know, I used to produce demos/intros in the C64 scene many years ago. I suspect the same culture lives on into PC/playstation/etc. The difference is the level of power available, and perhaps being able to use higher level tools. Anyone in the scene would treat so called 'games' or 'demo programming' books with horror and run a mile. Typically such books are aimed purely at trapping wannabe demo makers / coders and aren't really that useful. The advice is: look at existing demos/intros, start making your own, your first productions will possibly be not very good: improve, try again. If you are clever/intelligent/capable, then within a few iterations you'll start producing world class. Timeframe: 2 years.
Most of this discussion seems to be about interactive debugging tools, but as an individual concerned with mission critical telecommunications software where an outage can take out customer private networks, I tend to find less need for interactive debugging, and greater need for post-mortem diagnostic analysis that results from the following:
- faults generated in house system / integration testing
- faults generated in house automated unit / component testing
- faults generated in house automated system / scalability / performance testing
I need to isolate sometimes highly obscure run-time failures and discover what went wrong, then resolve the issue, which I do with:
- high levels of run-time instrumentation using (a) method / object / runtime c++ trace style classes, (b) trace back mechanisms for exception handling and, (c) assertion handling and (d) run-time verification mechanisms; all of which generate output to debug logs (sometimes when returned to support, these logs are multi-gigabyte in size, fortunately our development workstations are very high spec)
- post-mortem analysis scripts to interpret the contents of debug logs and look for faults, inconsistencies and other issues
- application level mechanisms to allow testing, deployment and other experts to enable run-time debug instrumentation (if it were enabled all the time, it would constitute considerable performance loss) sometimes at the direction of developers or deployment / field support personnel, and sometimes these personnel don't have access to machines where the components are installed (because the components are distributed CORBA components, and these personnel have access to host / user interfaces, but not to components in a silo in another country)
The problem is that we've had to design all of this from scratch: (a) general purpose c++ based debugging / tracing modules with command line / run time configuration options, (b) tools to stimulate the debugging facilities to do things [set / change debug trace levels / activation tags / identifiers], (c) tools to capture / wrap up and return trace logs back to support, including capturing host information (processes, memory, installed modules, environment, configuration) and other debugging items (debug stack traces, core dumps) and version information (component version, etc), (d) tools to analyse / work with / process logs for developers, (e) work instructions / process / documentation to educate developers, deployment experts and others about the use of these facilities, (f) make sure that there's a balance between getting the right level of detail, yet avoiding gigabytes of detailed code / method level information
Typically, once I have a debug log returned to me (as I am developer), I need to look at what was going on, and try to reproduce the fault with a unit test case, then inspect the component for faults of a similar type, and correct those with appropriate unit tests as well, then verify regression test for the component, make changes to multiple development branches, and wait for the scheduling of scalability / system / automated testing to ensure no other significant side effects, then safely know that the next release will have corrections.
We shouldn't have had to develop all of this in house: there should be standards for this. Other companies that I have worked with have the same adhoc construction of debugging facilities - for these situations were you need to analysis a running system, or obtain post-mortem results.
Interative debugging dwindles in comparison: unless you are working with obscure hardware, or related sorts of embedded systems, I think that an excessive need to use interative debugging says more about the lack of design / defensive coding / other engineering approaches to reliability of the constructed software. Interative debugging consumes about 10% of my debugging efforts (not including time spend on unit / component / system test design).
What irks me is that people with a degree assume that they are more talented and educated than people who are self educated. In many cases, the only difference between someone with a degree and someone without one is that piece of paper.
Hey, I hope you aren't suggesting that is what I meant: it works both ways, there are many talented and educated people that didn't go to university. But, at least university uses the wisdom of many many years of experience about learning processes and the brains trust of very good people. And lets talk about _averages_ here. We're talking that _on average_ people do better if they go to university than if they don't. There are always exceptions, and "stars" (and equally, "dropouts"), but speaking statistically, unless you are gifted, a genius, or have some special qualities about you that but you above the league in the first place, then the _chances are_ you're going to do better with a university education.
When you're 35 or 40 it's nothing but a worthless piece of paper when you have 15-20 years of experience behind you.
Not entirely true: it's value does decrease over time. This is why I say that you need to make use of your education: in 15 years time, mmany of your college educated peers are going to be in good positions having made a career, so if you're wise and have retained your connections, then you're making some use of your education more than just a piece of paper. But, I'm 10 years out of university, and I still draw upon my education.
Not entirely true. For instance, in engineering, you learn a lot of junk in university about forces, waves, systems, etc. Most of the actual content you learn turns out to be useless in your career (in my experience), but the underlying principles learnt (logical thinking, systems perspective, etc) are invaluable. In my years in industry, I see that non-university people learn all the technical skills, do their job well (and in many cases better) than the university graduates, but I consistently see the quality of approach / process in the university graduates that isn't in the non-graduates. I agree that you need _both_ work experience and university - many university graduates with no experience are not very practical or useful. The people that do extremely well are the ones that have a combination of both: they have the only the job work smarts and street smarts, and the get in there and do it approach, but they also have the methodical, systems, disciplined theorical balance that really only comes from a good university education.
You need to wait a few more years, and perhaps you need to more actively make value from your education. By the sounds of it, you're expecting the rest of the world to pay you back - life just doesn't work that way.
Take interest in professional associations, ensure that in your work assignments you make use of the skills you learnt (analytical, critical thinking, good judgement), retain connections with your peers in the industry from university, etc. Make better use of your education.
Studies show that after 5-10 years, university educated students catch up and surpass those that didn't go to university. University pays off eventually, but you have to make it work for you.