You seem to forget that we each need to have a $50000 cheque included with our protests; clearly we don't each have that, but the BSA/**AA do. That's also how things work.
You seem to forget that most of the people the big media corps have been going after lately have been breaking the law, often on a massive scale for an individual, and relying on the fact that the law could not be effectively enforced to get away with it. The personal losses now being suffered by everyone as a result of changes in the law were motivated by the personal greed of people who didn't follow the rules that were there already.
I certainly don't agree with the frivolous lawsuits where people are intimidated into settlements even when innocent. In more civilised legal systems, that sort of barratry is effectively prevented. Apparently the US system, where winner pays and endless battles using legal technicalities as weapons are not treated with contempt by the courts, is not as forgiving. Too bad for that legal system. The same authorities also seem unwilling to enforce the law where monopoly abuse and price fixing are concerned. Again, too bad for that legal system. Clearly there is a lot of corruption in the system and how it's applied today, but I'm not yet convinced that this particular case falls under that heading.
Many of the arguments we see around here are from people who were genuinely breaking reasonable law, and then trying to hide behind some sort of person liberty argument to argue against changes in the law that would all them to be caught. They brought it upon themselves (and, sadly, the rest of us), so screw 'em. No-one's personal rights and liberties extend to violating laws established using due process for benefit of everyone.
As other posters here have noted, this particular case is an example of exactly how the system should work: if someone's not happy, they should lobby for changes in the law; anyone opposed can make their arguments in return; and then the lawmakers will change the law if they deem it appropriate. There are financial arguments in favour of politicians seeking corporate backing, but ultimately, those lawmakers aren't accountable to corporations, as corporations don't have a vote. If you as citizens want to change the system, you have more power between you than all the corporations in the world to influence a politician, if you choose to use it.
Never doubt that a small group of thoughtful, committed citizens can change the world. Indeed, it is the only thing that ever has. --
Margaret Mead
That's a fair point, but even then the use of things like range-checked container classes rather than raw arrays was the norm amongst competent programmers, and the standard library vector class (which includes a range-checked indexing function) was widely known.
It may sound harsh, but I would describe any C++ programmer who (today) relies on raw arrays other than in very specific circumstances as "incompetent", assuming of course that their project's coding standards give them a better choice. Doing so demonstrates a fundamental misunderstanding about how to use the various tools C++ provides, which goes way beyond overlooking a simple buffer over-run somewhere.
Yes, this does mean that most C++ programmers are incompetent. If you think about it, that's why languages like Java, which offer similar mainstream features but enforce more safety, have become so popular. To uebergeek L337 Hax0rz, the limitations of these languages can be annoying, but to everyday project managers with everyday developers on their teams, the extra safety and reliability is worth more than the lost power tools.
If you can have buffer over-run vulnerabilities in your C++ app, then you are potentially vulnerable to absolutely anything.
roca replied:
Not really true.
I don't disagree with your comments about this specific vulnerability. My argument is more that if your development processes allow one buffer overflow, then you could allow any number of others, and potentially never notice.
The key point is that buffer over-runs really should never happen in C++, ever. The language provides a wide range of programming tools, and the kind of really low-level stuff that can achieve buffer over-runs -- pointer arithmetic or unchecked array indexing being the most likely culprits -- really should be confined to a small amount of very heavily tested library code.
That means if a buffer over-runs is ever detected, even once and even in beta code, then there is a serious flaw in the coding standards/code review processes/QA of the project. It implies that either unsafe tools are being used at too high a level, or that the reviews and standards for the low-level code are seriously deficient. In either case, if that's the project ethos, you can never trust that there aren't other over-runs that might be more exploitable elsewhere in the project. (It's also a bit of a killer for the "many eyes" theory of greater reliability for OSS projects, but perhaps that's best left for another discussion.)
Personally, I've always been quite impressed with the Mozilla browser/Firefox code quality. They seem to achieve a remarkably correct and reliable application. In this particular area, though, they clearly suck as much as many other projects (and even document that they do).
Thanks, but I had indeed spotted that. In fact, I already made a fairly damning comment on that particular coding standard elsewhere in the thread.
To answer your question, yes, Mozilla is a C++ app, but one which by design fails to take advantage of many of the safety and reliability benefits that C++ brings over C.:-(
But, unlike IE, these aren't 'You open a web page and your machine is taken over as a spam zombie' vulnerabilities. They should be fixed, but are less serious than the usual IE bugs...
If you can have buffer over-run vulnerabilities in your C++ app, then you are potentially vulnerable to absolutely anything. The fact that even one exists, even in a beta development, betrays fundamentally flawed coding standards and/or QA procedures. These things should never happen in a C++ app, and the coding techniques to prevent them are trivial.
and they'll likely be fixed a lot faster.
Easy, tiger. As others have pointed out, most exploits of Windows/IE systems use vulnerabilities that MS patched months ago, and when critical ones do come up, patches usually do appear (with much hype) PDQ.
Perhaps one reason is they are not really using C++ to its fullest extent like here as an example.
It's always depressing to see portability guides that say that sort of thing. (For those who didn't follow the link, it basically says don't use standard libs like iostreams.) C++ has been standardised since '98, with most players knowing the basic rules well before that. That's nearly a decade ago!
We have similar rules at work, where we do work with some seriously old compilers on a very portable code base. Even there, most of the rules restricting the use of certain language features that remain are anachronisms.
Bottom line: No-one should be using raw arrays without very careful scrutiny in C++ today. Coding standards should mandate the use of range-checked array indexing by default, which would probably have avoided this unfortunate mess.
AFAIK, the only name-brand players on the high street that aren't already multi-region (or at least hackable via remote) are Sony, because their ties with Columbia-Tristar mean they have a vested interest in maintaining the blatantly consumer-unfriendly region coding system alive. But even then, you can probably get chipped Sony players for a minimal premium from places like Richer Sounds anyway.
FWIW, even my local Sony Centre said their guys could chip a Sony DVD player for me before I collected for an extra twenty quid...
By law June 2005 is the last month any equipment can be made to ignore broadcast flags.
By law where, exactly? It sure as hell isn't law here in the UK, and I'm betting our export market in DRM-free DVD players/recorders will get an enormous boost around July 2005 if that's the case where you are.:-)
I'm typing this on a 23" Apple Cinema Screen LCD display, which I bought because it was gorgeous. Simple as. The fact that for significantly less cash I could have had 2 CRT's and a slightly larger screen real-estate didn't matter (which is saying something for me - I like having lots of windows open at once...). Looks matter:-)
In fairness, that monitor is the only one that's ever caused me to stop and turn my head in a computer shop and I nearly bought one on the spot. Unlike the CRT vs. flatscreen debate here, the Apple Cinema Display clearly does have much better image quality than any CRT, or for that matter any other flat panel monitor I've ever seen.
Show me a 60" CRT -- and if you can even find one, find a rec-room it would fit in, and try and lift it!
FWIW, if you're genuinely interested in that sort of size, you'd probably do much better with a projector-based set-up than with any sort of TV, flatscreen or otherwise.
The boxes may look cool, but having seriously investigated buying one a few months back, I was shocked at the image quality on plasma TVs. I'd rather keep my little 14" CRT in the corner of the room than blow 1,000+ on a 32" plasma screen where the image quality actually sucks in comparison.
Now, LCD-based technologies are a whole different matter. Curiously, they also seem to be quite a lot cheaper than plasma-based units right now, at least here in the UK. Go figure.:-)
Who do you think a company will pick, the person who spent their summer traveling through Europe or working summer camp, or the person who spent it working in a relevant field for the job?
Are we talking about people who both have an interest in programming and academic background to match, but one has been travelling for a few months while the other did a software development internship? If so, I think that's a very hard choice to make.
As is often observed, someone keen and with aptitude will learn the contemporary tools of the trade in today's IT world very fast. Joel himself mentions interns learning two or three "buzzword skills" in a single summer, for example. This is certainly valuable experience, and will give you a good start in your first real job. Still, while not all programming languages are equal (whatever some people might say) it's going to take more than a 2-3 month internship to put you a worthwhile distance ahead of a talented field in the medium-long term. You'll start ahead of the curve, but the curve will still be the same.
On the other hand, the people skills, independent thinking, planning and organisational skills, and extra maturity that you develop on an extended trip to foreign parts will be with you for life. Looking at the difference a gap year abroad (or a year abroad as part of a language degree) has made to those of my friends who took it, and comparing it with the benefits some other friends and I got out of "relevant" work experience, I'm absolutely sure with hindsight that those who went abroad got more out of it in the medium-long term. The only question is whether the short-term benefits of "hitting the ground running" in your first job post-university will be adequate compensation, and personally, I doubt it.
So far, all the jobs and good friendships I have gotten have been due to what I do outside school hours.
Good friendships, yes. Jobs? Not likely. My (UK) undergraduate degree was in maths, followed by a conversion to CS as a postgrad diploma (which basically means stuffing about 2/3 of an undergrad CS degree into an extended year). I've worked in a range of jobs involving software development, but my academic background has been both helpful in getting those jobs and useful while doing every one of them.
On the whole, I thought the article contained very good advice. That's particularly true of the suggestions about learning to speak English and getting relevant summer jobs, though the advice about programming/CS specifics wasn't bad either.
There is a difference between a text editor and a word processor...
Obviously: one's a practical tool that includes a comprehensive range of the useful features, and the other is a bloated anacronism that should have given up to proper DTP, web design or typesetting software around five years ago.;-)
But seriously, what amazes me about word processors today is that although they're almost always used for the same two jobs -- typing standard format documents like letters, or mini-DTP -- they still have such terrible support for things like templates/stylesheets, and for more advanced page layout features. There's an obvious advantage to having these features improved, and there's been support for the basics in every word processor for years, so its not like the dev teams haven't thought of it.
Another obvious place to look for improvements is in how the data is managed, and workflow improvement. Again, although word processors have been adding summary info and the like to their documents since forever, most places still rely on custom-designed (if they're designed at all) systems to keep track of all the correspondance sent to Customer X or reports written by Team Y.
Yet the effort all seems to be going into things like absurd "customisable solutions" branding, with all its attendant tweaking of UI and incorporation of programming languages. There hasn't been a major functional improvement in any word processor I can think of this millenium, but if all you're going to do is provide a blank page where people can type a letter and save it to a folder somewhere, you pretty much exhausted the possibilities there a couple of decades ago. I wonder whether Apple, long known for their attention to detail and shrewd product planning, can do better?
The 1980s just called, they want their silver bullet back.
LOL. I don't even slightly agree with you, but that was a good line.:-)
(I don't agree because VPLs aren't the same as CASE tools. I think they're one of those rite-of-passage ideas that many thinking programmers reinvent for themselves fairly early on. However, almost everyone who explores the idea more deeply discovers pretty quickly that there are scalability issues. Nothing in common knowledge today has yet overcome these. As long as it takes a whole page of diagram to represent a reasonably complex expression in a VPL, while the same takes a line or two of $TEXT_BASED_LANGUAGE, I'll stick to the latter. Thus they may indeed (not) be a silver bullet, but it's not the one from the '80s you appear to be thinking of.)
...modelling, used correctly...
on
How Do You Use UML?
·
· Score: 2, Interesting
I agree with much of your post, particularly these excerpts [emphasis added]:
I've done development for a very long time and there are few non-trivial projects where modeling,
used correctly, doesn't reduce risk and end up delivering a higher-quality product.
The art is to know how much modeling is enough.
And detailed modeling of stuff that doesn't matter is just bullshit.
To answer the original question, I find aspects of UML useful in two places:
While prototyping at the start of a new project, when I don't have any real code to play with yet, I often sketch out things like class diagrams and sequence diagrams.
Once a project is up and running and there's code around that someone else might have to navigate/understand. Automatically-generated class diagrams often provide a useful frame of reference if you're using an OO design.
Oddly, though apparently I'm not the only one, I usually prefer to do the prototyping work with the Mk. I Pen & Paper(TM). I find most "UML design software" hideously awkward to use. (If you do want to produce decent diagrams by hand, perhaps to put in a document that's being circulated to colleagues, then Pacestar's UML Diagrammer is the most simple-but-effective software I've found thus far, though of course YMMV.)
For documentation once the project is going, I subscribe to the view that the code should be mostly self-documenting as far as details go, but separate formal documentation should explain the "big picture" ideas. Tools like Doxygen are great for this. They generate class diagrams and such for you automatically, thus keeping everything up-to-date without much further effort on the part of the development team, but can also
provide a home for your written explanations of major ideas
reference key classes/functions in the generated areas of the docs, as a starting point for someone new to that area of code to find their way around
pick up summary comments at the start of functions and the like
thus keeping all your documentation in one place, without requiring error-prone manual duplicate of information you already wrote into the code.
IME processes that insist on using UML for anything more than either throwaway prototyping (when generated by humans) or reference material (when generated by software tools) tend to be far too heavyweight to be useful. In particular, I have never yet encountered a so-called "round trip engineering" process that actually did more good than harm. (That doesn't seem to stop many management teams deciding to mandate their use, alas!) Still, you can always waste plenty of afternoons trying to get that sequence diagram in Rational Rose to both look correct and work correctly if writing the equivalent C++ or Java in two minutes is too easy for you, and if that same enlightened management is paying you by the hour...;-)
This whole subthread is about that. Please go and read the original posts again.
Do you think that by creating something, and me using it, you're somehow entitled to full compensation?
That depends what you mean by "full compensation". Do you mean "fair compensation", in the sense that if others benefit from my work then I am entitled to proportionate compensation in return? If so, then morally yes. Anything else disadvantages the person actually creating the work in favour of the free-loader, which is not in the interests of society.
1) Someone, perhaps. Not enough someones to make up a paycheck.
So now it's OK to deprive someone of part of their rightful income by infringing their copyright, as long as it's not all of it? Perhaps it's wrong to keep their rent from them, but the money for their daughter's Christmas present doesn't matter?
Slashdot Mirror
You seem to forget that most of the people the big media corps have been going after lately have been breaking the law, often on a massive scale for an individual, and relying on the fact that the law could not be effectively enforced to get away with it. The personal losses now being suffered by everyone as a result of changes in the law were motivated by the personal greed of people who didn't follow the rules that were there already.
I certainly don't agree with the frivolous lawsuits where people are intimidated into settlements even when innocent. In more civilised legal systems, that sort of barratry is effectively prevented. Apparently the US system, where winner pays and endless battles using legal technicalities as weapons are not treated with contempt by the courts, is not as forgiving. Too bad for that legal system. The same authorities also seem unwilling to enforce the law where monopoly abuse and price fixing are concerned. Again, too bad for that legal system. Clearly there is a lot of corruption in the system and how it's applied today, but I'm not yet convinced that this particular case falls under that heading.
Many of the arguments we see around here are from people who were genuinely breaking reasonable law, and then trying to hide behind some sort of person liberty argument to argue against changes in the law that would all them to be caught. They brought it upon themselves (and, sadly, the rest of us), so screw 'em. No-one's personal rights and liberties extend to violating laws established using due process for benefit of everyone.
As other posters here have noted, this particular case is an example of exactly how the system should work: if someone's not happy, they should lobby for changes in the law; anyone opposed can make their arguments in return; and then the lawmakers will change the law if they deem it appropriate. There are financial arguments in favour of politicians seeking corporate backing, but ultimately, those lawmakers aren't accountable to corporations, as corporations don't have a vote. If you as citizens want to change the system, you have more power between you than all the corporations in the world to influence a politician, if you choose to use it.
That's a fair point, but even then the use of things like range-checked container classes rather than raw arrays was the norm amongst competent programmers, and the standard library vector class (which includes a range-checked indexing function) was widely known.
It may sound harsh, but I would describe any C++ programmer who (today) relies on raw arrays other than in very specific circumstances as "incompetent", assuming of course that their project's coding standards give them a better choice. Doing so demonstrates a fundamental misunderstanding about how to use the various tools C++ provides, which goes way beyond overlooking a simple buffer over-run somewhere.
Yes, this does mean that most C++ programmers are incompetent. If you think about it, that's why languages like Java, which offer similar mainstream features but enforce more safety, have become so popular. To uebergeek L337 Hax0rz, the limitations of these languages can be annoying, but to everyday project managers with everyday developers on their teams, the extra safety and reliability is worth more than the lost power tools.
I wrote:
roca replied:
I don't disagree with your comments about this specific vulnerability. My argument is more that if your development processes allow one buffer overflow, then you could allow any number of others, and potentially never notice.
The key point is that buffer over-runs really should never happen in C++, ever. The language provides a wide range of programming tools, and the kind of really low-level stuff that can achieve buffer over-runs -- pointer arithmetic or unchecked array indexing being the most likely culprits -- really should be confined to a small amount of very heavily tested library code.
That means if a buffer over-runs is ever detected, even once and even in beta code, then there is a serious flaw in the coding standards/code review processes/QA of the project. It implies that either unsafe tools are being used at too high a level, or that the reviews and standards for the low-level code are seriously deficient. In either case, if that's the project ethos, you can never trust that there aren't other over-runs that might be more exploitable elsewhere in the project. (It's also a bit of a killer for the "many eyes" theory of greater reliability for OSS projects, but perhaps that's best left for another discussion.)
Personally, I've always been quite impressed with the Mozilla browser/Firefox code quality. They seem to achieve a remarkably correct and reliable application. In this particular area, though, they clearly suck as much as many other projects (and even document that they do).
Thanks, but I had indeed spotted that. In fact, I already made a fairly damning comment on that particular coding standard elsewhere in the thread.
To answer your question, yes, Mozilla is a C++ app, but one which by design fails to take advantage of many of the safety and reliability benefits that C++ brings over C. :-(
But do you actually know that, or do you simply trust that it is true?
If you can have buffer over-run vulnerabilities in your C++ app, then you are potentially vulnerable to absolutely anything. The fact that even one exists, even in a beta development, betrays fundamentally flawed coding standards and/or QA procedures. These things should never happen in a C++ app, and the coding techniques to prevent them are trivial.
Easy, tiger. As others have pointed out, most exploits of Windows/IE systems use vulnerabilities that MS patched months ago, and when critical ones do come up, patches usually do appear (with much hype) PDQ.
No and yes, respectively.
Herein lies the fallacy behind much of the MS-bashing on threads like this.
It's always depressing to see portability guides that say that sort of thing. (For those who didn't follow the link, it basically says don't use standard libs like iostreams.) C++ has been standardised since '98, with most players knowing the basic rules well before that. That's nearly a decade ago!
We have similar rules at work, where we do work with some seriously old compilers on a very portable code base. Even there, most of the rules restricting the use of certain language features that remain are anachronisms.
Bottom line: No-one should be using raw arrays without very careful scrutiny in C++ today. Coding standards should mandate the use of range-checked array indexing by default, which would probably have avoided this unfortunate mess.
FWIW, even my local Sony Centre said their guys could chip a Sony DVD player for me before I collected for an extra twenty quid...
By law where, exactly? It sure as hell isn't law here in the UK, and I'm betting our export market in DRM-free DVD players/recorders will get an enormous boost around July 2005 if that's the case where you are. :-)
I rather suspect that, perhaps unlike the software he advocates, Bill Gates' own security is among the best in the world...
In fairness, that monitor is the only one that's ever caused me to stop and turn my head in a computer shop and I nearly bought one on the spot. Unlike the CRT vs. flatscreen debate here, the Apple Cinema Display clearly does have much better image quality than any CRT, or for that matter any other flat panel monitor I've ever seen.
FWIW, if you're genuinely interested in that sort of size, you'd probably do much better with a projector-based set-up than with any sort of TV, flatscreen or otherwise.
The boxes may look cool, but having seriously investigated buying one a few months back, I was shocked at the image quality on plasma TVs. I'd rather keep my little 14" CRT in the corner of the room than blow 1,000+ on a 32" plasma screen where the image quality actually sucks in comparison.
Now, LCD-based technologies are a whole different matter. Curiously, they also seem to be quite a lot cheaper than plasma-based units right now, at least here in the UK. Go figure. :-)
Dammit. Now we can't do the "All your game company are belong to us" joke...
Are we talking about people who both have an interest in programming and academic background to match, but one has been travelling for a few months while the other did a software development internship? If so, I think that's a very hard choice to make.
As is often observed, someone keen and with aptitude will learn the contemporary tools of the trade in today's IT world very fast. Joel himself mentions interns learning two or three "buzzword skills" in a single summer, for example. This is certainly valuable experience, and will give you a good start in your first real job. Still, while not all programming languages are equal (whatever some people might say) it's going to take more than a 2-3 month internship to put you a worthwhile distance ahead of a talented field in the medium-long term. You'll start ahead of the curve, but the curve will still be the same.
On the other hand, the people skills, independent thinking, planning and organisational skills, and extra maturity that you develop on an extended trip to foreign parts will be with you for life. Looking at the difference a gap year abroad (or a year abroad as part of a language degree) has made to those of my friends who took it, and comparing it with the benefits some other friends and I got out of "relevant" work experience, I'm absolutely sure with hindsight that those who went abroad got more out of it in the medium-long term. The only question is whether the short-term benefits of "hitting the ground running" in your first job post-university will be adequate compensation, and personally, I doubt it.
Maybe you should have followed his advice on learning to speak English effectively, too... ;-)
Good friendships, yes. Jobs? Not likely. My (UK) undergraduate degree was in maths, followed by a conversion to CS as a postgrad diploma (which basically means stuffing about 2/3 of an undergrad CS degree into an extended year). I've worked in a range of jobs involving software development, but my academic background has been both helpful in getting those jobs and useful while doing every one of them.
On the whole, I thought the article contained very good advice. That's particularly true of the suggestions about learning to speak English and getting relevant summer jobs, though the advice about programming/CS specifics wasn't bad either.
Obviously: one's a practical tool that includes a comprehensive range of the useful features, and the other is a bloated anacronism that should have given up to proper DTP, web design or typesetting software around five years ago. ;-)
But seriously, what amazes me about word processors today is that although they're almost always used for the same two jobs -- typing standard format documents like letters, or mini-DTP -- they still have such terrible support for things like templates/stylesheets, and for more advanced page layout features. There's an obvious advantage to having these features improved, and there's been support for the basics in every word processor for years, so its not like the dev teams haven't thought of it.
Another obvious place to look for improvements is in how the data is managed, and workflow improvement. Again, although word processors have been adding summary info and the like to their documents since forever, most places still rely on custom-designed (if they're designed at all) systems to keep track of all the correspondance sent to Customer X or reports written by Team Y.
Yet the effort all seems to be going into things like absurd "customisable solutions" branding, with all its attendant tweaking of UI and incorporation of programming languages. There hasn't been a major functional improvement in any word processor I can think of this millenium, but if all you're going to do is provide a blank page where people can type a letter and save it to a folder somewhere, you pretty much exhausted the possibilities there a couple of decades ago. I wonder whether Apple, long known for their attention to detail and shrewd product planning, can do better?
LOL. I don't even slightly agree with you, but that was a good line. :-)
(I don't agree because VPLs aren't the same as CASE tools. I think they're one of those rite-of-passage ideas that many thinking programmers reinvent for themselves fairly early on. However, almost everyone who explores the idea more deeply discovers pretty quickly that there are scalability issues. Nothing in common knowledge today has yet overcome these. As long as it takes a whole page of diagram to represent a reasonably complex expression in a VPL, while the same takes a line or two of $TEXT_BASED_LANGUAGE, I'll stick to the latter. Thus they may indeed (not) be a silver bullet, but it's not the one from the '80s you appear to be thinking of.)
I agree with much of your post, particularly these excerpts [emphasis added]:
To answer the original question, I find aspects of UML useful in two places:
Oddly, though apparently I'm not the only one, I usually prefer to do the prototyping work with the Mk. I Pen & Paper(TM). I find most "UML design software" hideously awkward to use. (If you do want to produce decent diagrams by hand, perhaps to put in a document that's being circulated to colleagues, then Pacestar's UML Diagrammer is the most simple-but-effective software I've found thus far, though of course YMMV.)
For documentation once the project is going, I subscribe to the view that the code should be mostly self-documenting as far as details go, but separate formal documentation should explain the "big picture" ideas. Tools like Doxygen are great for this. They generate class diagrams and such for you automatically, thus keeping everything up-to-date without much further effort on the part of the development team, but can also
- provide a home for your written explanations of major ideas
- reference key classes/functions in the generated areas of the docs, as a starting point for someone new to that area of code to find their way around
- pick up summary comments at the start of functions and the like
thus keeping all your documentation in one place, without requiring error-prone manual duplicate of information you already wrote into the code.IME processes that insist on using UML for anything more than either throwaway prototyping (when generated by humans) or reference material (when generated by software tools) tend to be far too heavyweight to be useful. In particular, I have never yet encountered a so-called "round trip engineering" process that actually did more good than harm. (That doesn't seem to stop many management teams deciding to mandate their use, alas!) Still, you can always waste plenty of afternoons trying to get that sequence diagram in Rational Rose to both look correct and work correctly if writing the equivalent C++ or Java in two minutes is too easy for you, and if that same enlightened management is paying you by the hour... ;-)
Except that most TLAs are abbreviations and not acronyms, including this one...
See also: SA (shortened abbreviation), ETLA (extended three-letter abbreviation), DETLA (doubly-extended three-letter abbreviation), etc.
Hey, at least it wasn't (-1, Overrated), which is shorthand for "You suck, because." :-)
This whole subthread is about that. Please go and read the original posts again.
That depends what you mean by "full compensation". Do you mean "fair compensation", in the sense that if others benefit from my work then I am entitled to proportionate compensation in return? If so, then morally yes. Anything else disadvantages the person actually creating the work in favour of the free-loader, which is not in the interests of society.
So now it's OK to deprive someone of part of their rightful income by infringing their copyright, as long as it's not all of it? Perhaps it's wrong to keep their rent from them, but the money for their daughter's Christmas present doesn't matter?