I think this is the other way around, isn't it? For integrating Windows stations into primarily Unix environments? As far as I know, this runs on Windows and allows it to better interact with NIS setups, but does nothing for *nix boxes in Active Directory environments.
Actually, my observation is that Gates is focused on addressing traditional charity problems and is more interested in putting out charitable money for its own sake, whereas Paul puts his funds into stuff that he thinks is cool. Some of that stuff has added benefits, which is great, and I am sure that's a factor for him--but I think mostly it's just because it's stuff that he has always wanted to do (and most likely that you or I would want to do) given a few billion dollars to throw around.
Bill invests in the Third World and putting computers in schools. Paul puts up EMP, renovates Cinerama, buys a few sports teams, and throws some cash at building better rocket ships. Which of these is someone going out and consciously adopting the 'charitable millionair' veneer and which is a regular guy that suddenly became fabulously wealthy doing the cool stuff he fantasized about before all that money?
I think they are both doing excellent things with their money, especially considering that there are so many tremendously wealthy people who don't. And it's great living in Seattle and reaping some of the benefits of Paul reliving his youth, too.;)
Not only that, but frankly, if software were developed a bit more professionaly, there would hardly be need for so many 'psuedo-admin' roles that become necessary not simply out of some expression of corporate bloat, but generally because the crap that devs churn out needs handholding by someone with a bit better understanding than most end-users can be expected to have. If this is a problem now--and I would tend to agree that it is--it's one of the development community's own making.
Don't want source code adminstrators? Learn to manage your own source so that it isn't lost or mucked up without someone tracking it specifically. That job didn't just materialize out of thin air, you know... some disaster at some point in the past made some PHB sit back and say "Hey, why don't we have someone managing this so that sort of thing doesn't happen?"
Security admins? Try cranking out code that isn't full of potential exploits. The rise of dedicated security admins has coincided exactly with the danger and frequency of software-based system compromise. Do you think anyone would have hired that guy if there wasn't suddenly a flood of holes to be closed and patches to be applied which overwhelmed the existing staff?
PC Admin? This guy goes on a rant about virus-checkers, when the only reason we need to run them is because of crap programs that allow viruses in the first place?
His most basic mistake is the same that he is accusing admins of--assuming that development is the end-all of the universe. I think both devs and admins have a problem understanding this, but the truth is that the business is the most important thing, and frankly, most admins are slightly better at addressing the overall needs of businesses than most developers. Development efficiency is not the most important factor in any corporation whose business isn't software development... in other words, most of them. The author's assumption that it is is the underlying fault with the entire article.
As I understand it (which may well be imperfectly) the decoder is in the firmware in the device, not the Perl code. And if I recall correctly (which I almost certainly don't) the reason Ogg wasn't originally supported on the firmware was because the chip in the device didn't have the oomph to decode an Ogg stream on the fly.
As far as the Perl/server-side is concerned, you can already stream.ogg files. But there's nothing you can do there to add support to the firmware.
Actually, it's interesting that no one has mentioned wildland firefighting in this discussion yet. Although I think you're right that the basic techniques of combatting wildfires hasn't changed very much--and probably won't in the foreseeable future--I think there have been tremendous technological changes in determining when and where wildfires are fought.
The most obvious change has been lightning detectors. There are very few fire lookouts staffed these days; automated detection systems plot where strikes hit, and planes can check out almost immediately if they have started a fire or not. Ground-based systems are still prevalent but there are now orbital imaging systems coming into play to do the same thing, with even greater accuracy.
Every leap in weather forecasting has helped wildland firefighters. Knowing when the wind and humidity are going to be on your side is a critical factor for deciding when to take on the fire and when to stay back. Being able to assess these factors in the field with smaller and better detection equipment has changed the nature of the game.
Helicopters, parachutes, air-drops... these are all fairly recent innovations that have dramatically expanded options for firebosses.
Then there are the more pedestrian advances, such as GPS and lightweight mountain gear, which benefit any backcountry traveler, but of course also make life easier for people who are not only having to fight a monstrous wildfire, but having to hike some of the most rugged terrain in the world to do so.
I'd say there have been more changes from technology in wildland firefighting in the last hundred years than there have been in structural firefighting--they're just not as obvious.
Plus, as far as I remember, you don't usually vent until you have a supplied line in position to attack with. To attack without venting the structure is begging for a flashover; it's a technique that's been in use for years and years. PPV is a pretty neat trick to amplify the effect, though.
Heh... I never thought about that, but the same is probably true for me. I just usually toss them into a box and haul them back out when needed--difficult to say which is oldest or where from.
Oldest integrated piece of hardware I am still REGULARLY using is the 3.5" floppy from my 386. That's made the transition with me through just about every generation of architecture up through my new Athlon. From habit, I still have the 5.25" drive installed too, but it's been so long since I've used it I couldn't swear that it works--nor am I sure I have any disks around anymore to actually test it with.
And you found the point at which the analogy breaks down there--computers and operating systems are far more versatile than pipe wrenches and paint brushes. A 'basic' computer toolset serves as a base for the advanced tools, where the same is not true for tools in the trades (unless you want to REALLY stretch it and start talking about air compressors and ladders and trucks and such;) ).
But you are right; it's folly to proceed under the assumption that one-size fits all will work. My point is just that the other assumption, that best of breed is automatically better (and I think that is the more common assumption), is just as folly and that it isn't until you sit down and do the numbers that you have a real inkling either way.
Well, the problem with most places is that the original setup is just a starting point--management doesn't just want you to set something up and run it, they want new features, new capabilities, and you end up with a more or less constantly evolving environment. If it was set it up and forget it, it would be a different story, I agree.
And my impression on the platform diversity issue is that it's really an advantage to the global matrix of sites, rather than specific sites--lack of diversity both encourages exploration and development of exploits and increases their possible rate of spread, but those are things that are not much of a factor unless taken in a larger context than at a single organization (except very large ones). If I have three different platforms to support three different departments, it does me little good if two of them are working when the third is taken out. Diversification to the level that would prevent that sort of problem wouldn't be even remotely cost effective, IMHO.
I think we're basically of the same mind, then. Standards are essentially restrictions on what can be installed, and I agree that is the key to smoothly operating most environments.
You definitely have to tailor things to your user base. If you can get away with not having to explain every little thing, and they can figure most issues out on there own, then you are in a different place from most businesses and have a lot more of your own time to keep everything else running smoothly. I'd have to hire a Mac guy, a Windows guy, a *nix guy to get away with that with as many users and as much turnover as we have. Not to mention the issues that would come up with five different departments all wanting custom, interfacing systems based on different platforms. I can't imagine any scenario in which that would be a fun day at the beach.:)
I'm not sure I would consider that a corporate environment. It sounds a lot like my home network; which like you, is something I do because I like doing it. I may be off base saying this and I am not minimizing your expertise, but I tend to think that if you are doing all that on your own, keeping up easily, and not running into any of the headaches that standardization fix, then you are probably not facing a very challenging environment.
Certainly at my company, with the level of expertise and education of my users, you would be busy just answering phones full-time explaining how to get Word to print sideways. I've got a guy who does that; if you have a magic pill I can hand out that will cure all our hammer-swingers, I'll fire him and pay you his salary and you can play Quake or whatever you'd like all day instead.;)
Oddly enough, it's a construction company we are talking about.:)
It shouldn't baffle you, though. In fact, you tell most of the story in your analogy. Among those professions you listed, who doesn't use a hammer and screwdriver? Do they all have to be separate brands?
IT, in some senses, is strictly a cost liability in most organizations. What on earth is wrong with wanting to minimize that cost--to enable them to do that unprofitable but necessary job better and faster?
What it requires is an ability to see beyond the seemingly obvious--give the users the best tools possible for their specific jobs to get the best possible efficiency--and look to the reality of the situation. And that reality is, in most cases, that giving the users what they think are the best tools for their own efficiency does not improve their productivity past the point where it becomes cost-effective for IT to support them. I see it all the time--businesses hemorrhaging dollars because they have shelled out for a dozen 'best of breed' solutions for each department, which they then have to pour more dollars into supporting than the projected savings were over the 'brand X' solution.
This is something that is by no means universal, but when I have actually run the numbers, is true more often than not. It seems intuitive that you will do better by giving the users exactly what they want, but when you actually sit down and do the math, it's often simply untrue.
I suspect a lot of this has to do with the differences between what people want and what they need, and the fact that technology is still complicated enough that an educated IT professional can still do a better job of picking out what a user needs than the user can... few have the expertise to sift through the marketing jingo on their own, or to see the larger picture where interoperability becomes a factor. The same is not true for the trades that you mentioned; the sort of brush a painter uses has no effect on the pipe wrench a plumber chooses.
But I suspect you would find that someone will always claim there is something they can't do no matter what platform you standardize on--which is what we are really talking about here, not which offers the best standard.
In my experience, when I've told someone I can't support something and they tell me they'll just handle it, it almost inevitably turns into my problem anyway. Most people who assume they can 'just handle it' are geniuses who run one or two boxes at home and don't have a clue at the issues they're going to run into in a corporate environment.
Standards are sucky things if you are looking for the most efficient way to perform a particular function in an organization, but they are a necessity if you want to run a smooth and cost-effective operation overall. Would it be best if I could give our people who do graphics Macs, and run our website off Linux, and provide the accounting department with the latest and greatest version of Excel? You bet, they would all love it. But then I'd have to staff the FTE to keep up with three different systems' worth of problems and patches and interoperability quirks and maintain up to date expertise in all of them. And presenting THAT bill to management would not go over well.
I've tried running open systems for people who think they can 'just handle it' and it has never, ever been worth it in the long run. Whatever efficiencies they imagine they are bringing to their own personal job, it has always come at a larger cost to the organization as a whole than any individualized savings have been worth.
Especially in network documentation. Nothing beats back a snarl of wiring (even if you were neat, you know by the time someone else is going to have to work on it, it will be a mess) like some old-fashioned line drawings. And remember, only half the documentation is what you are writing down--the rest is in clear labeling of cables, equipment, and machines.
Aside from that, what some guy said above is perfect--a broad-sketch overview, a sort of narrative description of how everything works and fits together, and then detailed drill-downs in specific systems and sub-systems. No point in forcing someone to go through twenty paragraphs of detail when all they need to know is what Router A is supposed to connect to. The overview is often the most valuable part of the documentation.
I just use a basic outline format usually, but as long as there is a table of contents and some sort of logical progression to it, I don't think it probably matters too much.
Good documentation is what really distinguishes professionals from amateurs in this business.
I have a fun story about bad headhunters who won't do that; it's how I ended up in my current position, in a roundabout sort of way.
The headhunter set up my interview with this company. I went in and talked with the company and it went well, on the level that there was a lot of mutual understanding. The understanding, however, was that neither of us were sure whether it was a good match. They weren't sure that I would fit in and I wasn't sure I wanted to. So we talked about it and decided a contract to hire offer would be best.
I convey this to the recruiter; he says, "But we don't do contract to hire placements." I shrug, tell him that's what his client was looking for too, he could talk it over with them, and that if that was the arrangement then I would take the position. He's adamant that the firm simply does not do that sort of placement. I say, "But that's what I want, that's what the client wants--if neither of us get what we are looking for, how do you expect to get compensated?" I tell him to figure it out and get back to me.
He calls me back the next day--tells me they are not interested. I'm a little confused; they had seemed interested enough when I was there. I decided to call and see what the issue had been--I dug out the card they'd given me and called up one of the people I interviewed with. Was she ever surprised! The recruiter, it developed, had told them that I was not interested in any contract to hire arrangements. I quickly disabused her of that notion, and went over the next day to chat more about it. Within a week, we'd hammered out an arrangement. Without mentioning it to the recruiter. He called me back a few times after but I always came up with 'scheduling conflicts' for his interview proposals with other companies and eventually he stopped calling. They never got a dime out of the deal, even though it's three years later now and I took the position full time after six months on contract. And I certainly won't be recommending that firm to anyone (won't mention them here, lest it get my current employer in court).:)
Yes, that is a democracy. Which is why it's such a great thing that we don't live in one. We're a democratic republic, which is not the same thing as 'majority rules'.
That's a sale, not a contract... someone else pointed this out above as well, but legally they are not the same thing. Not that you need bother to get drunk to avoid meeting the basic obligations of a contract when faced with an EULA... there are so many ways they don't comport to the existing law it's beyond a joke.
If he started making money off of it, someone would be interested, pretty fast.
Even if he finds and contacts the IP owner, the simple fact that he is interested at all in procuring the rights will probably raise some interest, unless they are completely apathetic or very cool.
Ah, but it brings up the thornier issue of, would the person have bought the product at the price available if it were not available for free? This is a bit like the Department of Pre-Crime, isn't it? Although there are definitely sales lost to shared files, there is no way to prove in any specific case that it resulted in a lost sale. In our system of justice, you do have to actually commit the crime before you can be convicted of it (note that conspiracy to murder and murder are different charges and carry different sentencing guidelines--appropriately so).
Now, not buying an album isn't a crime, but it's using the same logic that I object to the theft analogy for filesharing. It assumes something that should not be assumed in our system of justice--that a downloaded file is equivalent to a lost sale in every case. I know that's not true for me personally--I download a lot to check something out, end up deleting half of it, and never would have checked the artist out in the first place if I had to shell out $16 for a CD. I think many, if not the majority, of filetraders are like that.
Which is not to say it doesn't violate a law--it does--but it's not a law that at all resembles theft. The basic intents of copyright and property laws are completely different. Laws against stealing property are designed to protect an individual's right to own and hold property; laws against infringing copyright are designed to promote the public's right to access intellectual works and ideas. Copyright allows the holder to pad his pockets only as an incentive to release the work, not as a basic right like property ownership.
Now, in the lawyer's defense, he was talking about piracy. I don't know about him, but I view piracy and run of the mill filesharing as separate issues. This guy is used to prosecuting criminal cases, as he says repeatedly--those are usually when someone is into the game for profit, which is what I think of as 'piracy'. That is certainly closer to theft, because it does have the intent of depriving legitimate sales by trickery. Phrased more carefully, he may not have drawn the same analogy for some kid sitting in his parent's basement checking out the latest Britney song.
There may be a better example... it seems I hear every few months of someone suing the crap out of their insurance company for failing to cover something or over. In fact, wasn't there just a decision last week in court about mandatory coverage for contraceptives?
Anyway; you really can't sign away your rights. You can sign a piece of paper saying that you are relinquishing them, but it wouldn't be binding. It's just a scare tactic for the most part, like overly restrictive non-competes.
On a more serious note, it's not necessarily a problem with priviledges... it's more to do with audits and cranky IT departments. Although I am the cranky IT department here. But still... it's not an accurate assumption to believe that everyone with the capability of running this stuff can do so without repercussion.
Slashdot Mirror
I think this is the other way around, isn't it? For integrating Windows stations into primarily Unix environments? As far as I know, this runs on Windows and allows it to better interact with NIS setups, but does nothing for *nix boxes in Active Directory environments.
Actually, my observation is that Gates is focused on addressing traditional charity problems and is more interested in putting out charitable money for its own sake, whereas Paul puts his funds into stuff that he thinks is cool. Some of that stuff has added benefits, which is great, and I am sure that's a factor for him--but I think mostly it's just because it's stuff that he has always wanted to do (and most likely that you or I would want to do) given a few billion dollars to throw around.
;)
Bill invests in the Third World and putting computers in schools. Paul puts up EMP, renovates Cinerama, buys a few sports teams, and throws some cash at building better rocket ships. Which of these is someone going out and consciously adopting the 'charitable millionair' veneer and which is a regular guy that suddenly became fabulously wealthy doing the cool stuff he fantasized about before all that money?
I think they are both doing excellent things with their money, especially considering that there are so many tremendously wealthy people who don't. And it's great living in Seattle and reaping some of the benefits of Paul reliving his youth, too.
Not only that, but frankly, if software were developed a bit more professionaly, there would hardly be need for so many 'psuedo-admin' roles that become necessary not simply out of some expression of corporate bloat, but generally because the crap that devs churn out needs handholding by someone with a bit better understanding than most end-users can be expected to have. If this is a problem now--and I would tend to agree that it is--it's one of the development community's own making.
Don't want source code adminstrators? Learn to manage your own source so that it isn't lost or mucked up without someone tracking it specifically. That job didn't just materialize out of thin air, you know... some disaster at some point in the past made some PHB sit back and say "Hey, why don't we have someone managing this so that sort of thing doesn't happen?"
Security admins? Try cranking out code that isn't full of potential exploits. The rise of dedicated security admins has coincided exactly with the danger and frequency of software-based system compromise. Do you think anyone would have hired that guy if there wasn't suddenly a flood of holes to be closed and patches to be applied which overwhelmed the existing staff?
PC Admin? This guy goes on a rant about virus-checkers, when the only reason we need to run them is because of crap programs that allow viruses in the first place?
His most basic mistake is the same that he is accusing admins of--assuming that development is the end-all of the universe. I think both devs and admins have a problem understanding this, but the truth is that the business is the most important thing, and frankly, most admins are slightly better at addressing the overall needs of businesses than most developers. Development efficiency is not the most important factor in any corporation whose business isn't software development... in other words, most of them. The author's assumption that it is is the underlying fault with the entire article.
As I understand it (which may well be imperfectly) the decoder is in the firmware in the device, not the Perl code. And if I recall correctly (which I almost certainly don't) the reason Ogg wasn't originally supported on the firmware was because the chip in the device didn't have the oomph to decode an Ogg stream on the fly.
.ogg files. But there's nothing you can do there to add support to the firmware.
As far as the Perl/server-side is concerned, you can already stream
Actually, it's interesting that no one has mentioned wildland firefighting in this discussion yet. Although I think you're right that the basic techniques of combatting wildfires hasn't changed very much--and probably won't in the foreseeable future--I think there have been tremendous technological changes in determining when and where wildfires are fought.
The most obvious change has been lightning detectors. There are very few fire lookouts staffed these days; automated detection systems plot where strikes hit, and planes can check out almost immediately if they have started a fire or not. Ground-based systems are still prevalent but there are now orbital imaging systems coming into play to do the same thing, with even greater accuracy.
Every leap in weather forecasting has helped wildland firefighters. Knowing when the wind and humidity are going to be on your side is a critical factor for deciding when to take on the fire and when to stay back. Being able to assess these factors in the field with smaller and better detection equipment has changed the nature of the game.
Helicopters, parachutes, air-drops... these are all fairly recent innovations that have dramatically expanded options for firebosses.
Then there are the more pedestrian advances, such as GPS and lightweight mountain gear, which benefit any backcountry traveler, but of course also make life easier for people who are not only having to fight a monstrous wildfire, but having to hike some of the most rugged terrain in the world to do so.
I'd say there have been more changes from technology in wildland firefighting in the last hundred years than there have been in structural firefighting--they're just not as obvious.
Plus, as far as I remember, you don't usually vent until you have a supplied line in position to attack with. To attack without venting the structure is begging for a flashover; it's a technique that's been in use for years and years. PPV is a pretty neat trick to amplify the effect, though.
Heh... I never thought about that, but the same is probably true for me. I just usually toss them into a box and haul them back out when needed--difficult to say which is oldest or where from.
Oldest integrated piece of hardware I am still REGULARLY using is the 3.5" floppy from my 386. That's made the transition with me through just about every generation of architecture up through my new Athlon. From habit, I still have the 5.25" drive installed too, but it's been so long since I've used it I couldn't swear that it works--nor am I sure I have any disks around anymore to actually test it with.
And you found the point at which the analogy breaks down there--computers and operating systems are far more versatile than pipe wrenches and paint brushes. A 'basic' computer toolset serves as a base for the advanced tools, where the same is not true for tools in the trades (unless you want to REALLY stretch it and start talking about air compressors and ladders and trucks and such ;) ).
But you are right; it's folly to proceed under the assumption that one-size fits all will work. My point is just that the other assumption, that best of breed is automatically better (and I think that is the more common assumption), is just as folly and that it isn't until you sit down and do the numbers that you have a real inkling either way.
Well, the problem with most places is that the original setup is just a starting point--management doesn't just want you to set something up and run it, they want new features, new capabilities, and you end up with a more or less constantly evolving environment. If it was set it up and forget it, it would be a different story, I agree.
And my impression on the platform diversity issue is that it's really an advantage to the global matrix of sites, rather than specific sites--lack of diversity both encourages exploration and development of exploits and increases their possible rate of spread, but those are things that are not much of a factor unless taken in a larger context than at a single organization (except very large ones). If I have three different platforms to support three different departments, it does me little good if two of them are working when the third is taken out. Diversification to the level that would prevent that sort of problem wouldn't be even remotely cost effective, IMHO.
I think we're basically of the same mind, then. Standards are essentially restrictions on what can be installed, and I agree that is the key to smoothly operating most environments.
:)
You definitely have to tailor things to your user base. If you can get away with not having to explain every little thing, and they can figure most issues out on there own, then you are in a different place from most businesses and have a lot more of your own time to keep everything else running smoothly. I'd have to hire a Mac guy, a Windows guy, a *nix guy to get away with that with as many users and as much turnover as we have. Not to mention the issues that would come up with five different departments all wanting custom, interfacing systems based on different platforms. I can't imagine any scenario in which that would be a fun day at the beach.
I'm not sure I would consider that a corporate environment. It sounds a lot like my home network; which like you, is something I do because I like doing it. I may be off base saying this and I am not minimizing your expertise, but I tend to think that if you are doing all that on your own, keeping up easily, and not running into any of the headaches that standardization fix, then you are probably not facing a very challenging environment.
;)
Certainly at my company, with the level of expertise and education of my users, you would be busy just answering phones full-time explaining how to get Word to print sideways. I've got a guy who does that; if you have a magic pill I can hand out that will cure all our hammer-swingers, I'll fire him and pay you his salary and you can play Quake or whatever you'd like all day instead.
Oddly enough, it's a construction company we are talking about. :)
It shouldn't baffle you, though. In fact, you tell most of the story in your analogy. Among those professions you listed, who doesn't use a hammer and screwdriver? Do they all have to be separate brands?
IT, in some senses, is strictly a cost liability in most organizations. What on earth is wrong with wanting to minimize that cost--to enable them to do that unprofitable but necessary job better and faster?
What it requires is an ability to see beyond the seemingly obvious--give the users the best tools possible for their specific jobs to get the best possible efficiency--and look to the reality of the situation. And that reality is, in most cases, that giving the users what they think are the best tools for their own efficiency does not improve their productivity past the point where it becomes cost-effective for IT to support them. I see it all the time--businesses hemorrhaging dollars because they have shelled out for a dozen 'best of breed' solutions for each department, which they then have to pour more dollars into supporting than the projected savings were over the 'brand X' solution.
This is something that is by no means universal, but when I have actually run the numbers, is true more often than not. It seems intuitive that you will do better by giving the users exactly what they want, but when you actually sit down and do the math, it's often simply untrue.
I suspect a lot of this has to do with the differences between what people want and what they need, and the fact that technology is still complicated enough that an educated IT professional can still do a better job of picking out what a user needs than the user can... few have the expertise to sift through the marketing jingo on their own, or to see the larger picture where interoperability becomes a factor. The same is not true for the trades that you mentioned; the sort of brush a painter uses has no effect on the pipe wrench a plumber chooses.
We don't. That's exactly my point. Thank you. :)
But I suspect you would find that someone will always claim there is something they can't do no matter what platform you standardize on--which is what we are really talking about here, not which offers the best standard.
In my experience, when I've told someone I can't support something and they tell me they'll just handle it, it almost inevitably turns into my problem anyway. Most people who assume they can 'just handle it' are geniuses who run one or two boxes at home and don't have a clue at the issues they're going to run into in a corporate environment.
Standards are sucky things if you are looking for the most efficient way to perform a particular function in an organization, but they are a necessity if you want to run a smooth and cost-effective operation overall. Would it be best if I could give our people who do graphics Macs, and run our website off Linux, and provide the accounting department with the latest and greatest version of Excel? You bet, they would all love it. But then I'd have to staff the FTE to keep up with three different systems' worth of problems and patches and interoperability quirks and maintain up to date expertise in all of them. And presenting THAT bill to management would not go over well.
I've tried running open systems for people who think they can 'just handle it' and it has never, ever been worth it in the long run. Whatever efficiencies they imagine they are bringing to their own personal job, it has always come at a larger cost to the organization as a whole than any individualized savings have been worth.
Especially in network documentation. Nothing beats back a snarl of wiring (even if you were neat, you know by the time someone else is going to have to work on it, it will be a mess) like some old-fashioned line drawings. And remember, only half the documentation is what you are writing down--the rest is in clear labeling of cables, equipment, and machines.
Aside from that, what some guy said above is perfect--a broad-sketch overview, a sort of narrative description of how everything works and fits together, and then detailed drill-downs in specific systems and sub-systems. No point in forcing someone to go through twenty paragraphs of detail when all they need to know is what Router A is supposed to connect to. The overview is often the most valuable part of the documentation.
I just use a basic outline format usually, but as long as there is a table of contents and some sort of logical progression to it, I don't think it probably matters too much.
Good documentation is what really distinguishes professionals from amateurs in this business.
I have a fun story about bad headhunters who won't do that; it's how I ended up in my current position, in a roundabout sort of way.
:)
The headhunter set up my interview with this company. I went in and talked with the company and it went well, on the level that there was a lot of mutual understanding. The understanding, however, was that neither of us were sure whether it was a good match. They weren't sure that I would fit in and I wasn't sure I wanted to. So we talked about it and decided a contract to hire offer would be best.
I convey this to the recruiter; he says, "But we don't do contract to hire placements." I shrug, tell him that's what his client was looking for too, he could talk it over with them, and that if that was the arrangement then I would take the position. He's adamant that the firm simply does not do that sort of placement. I say, "But that's what I want, that's what the client wants--if neither of us get what we are looking for, how do you expect to get compensated?" I tell him to figure it out and get back to me.
He calls me back the next day--tells me they are not interested. I'm a little confused; they had seemed interested enough when I was there. I decided to call and see what the issue had been--I dug out the card they'd given me and called up one of the people I interviewed with. Was she ever surprised! The recruiter, it developed, had told them that I was not interested in any contract to hire arrangements. I quickly disabused her of that notion, and went over the next day to chat more about it. Within a week, we'd hammered out an arrangement. Without mentioning it to the recruiter. He called me back a few times after but I always came up with 'scheduling conflicts' for his interview proposals with other companies and eventually he stopped calling. They never got a dime out of the deal, even though it's three years later now and I took the position full time after six months on contract. And I certainly won't be recommending that firm to anyone (won't mention them here, lest it get my current employer in court).
Yes, that is a democracy. Which is why it's such a great thing that we don't live in one. We're a democratic republic, which is not the same thing as 'majority rules'.
That's a sale, not a contract... someone else pointed this out above as well, but legally they are not the same thing. Not that you need bother to get drunk to avoid meeting the basic obligations of a contract when faced with an EULA... there are so many ways they don't comport to the existing law it's beyond a joke.
Nah, man... who is gonna buy all that copyrighted material after they are dead?
If he started making money off of it, someone would be interested, pretty fast.
Even if he finds and contacts the IP owner, the simple fact that he is interested at all in procuring the rights will probably raise some interest, unless they are completely apathetic or very cool.
Ah, but it brings up the thornier issue of, would the person have bought the product at the price available if it were not available for free? This is a bit like the Department of Pre-Crime, isn't it? Although there are definitely sales lost to shared files, there is no way to prove in any specific case that it resulted in a lost sale. In our system of justice, you do have to actually commit the crime before you can be convicted of it (note that conspiracy to murder and murder are different charges and carry different sentencing guidelines--appropriately so).
Now, not buying an album isn't a crime, but it's using the same logic that I object to the theft analogy for filesharing. It assumes something that should not be assumed in our system of justice--that a downloaded file is equivalent to a lost sale in every case. I know that's not true for me personally--I download a lot to check something out, end up deleting half of it, and never would have checked the artist out in the first place if I had to shell out $16 for a CD. I think many, if not the majority, of filetraders are like that.
Which is not to say it doesn't violate a law--it does--but it's not a law that at all resembles theft. The basic intents of copyright and property laws are completely different. Laws against stealing property are designed to protect an individual's right to own and hold property; laws against infringing copyright are designed to promote the public's right to access intellectual works and ideas. Copyright allows the holder to pad his pockets only as an incentive to release the work, not as a basic right like property ownership.
Now, in the lawyer's defense, he was talking about piracy. I don't know about him, but I view piracy and run of the mill filesharing as separate issues. This guy is used to prosecuting criminal cases, as he says repeatedly--those are usually when someone is into the game for profit, which is what I think of as 'piracy'. That is certainly closer to theft, because it does have the intent of depriving legitimate sales by trickery. Phrased more carefully, he may not have drawn the same analogy for some kid sitting in his parent's basement checking out the latest Britney song.
There may be a better example... it seems I hear every few months of someone suing the crap out of their insurance company for failing to cover something or over. In fact, wasn't there just a decision last week in court about mandatory coverage for contraceptives?
Anyway; you really can't sign away your rights. You can sign a piece of paper saying that you are relinquishing them, but it wouldn't be binding. It's just a scare tactic for the most part, like overly restrictive non-competes.
I just got this crazy mental picture of a crew of burly blonde men trying to heft an oil drum sized silencer onto a 155mm howitzer.
Forgive me, but where on Earth would you use silencer in the Swedish artillery?
On a more serious note, it's not necessarily a problem with priviledges... it's more to do with audits and cranky IT departments. Although I am the cranky IT department here. But still... it's not an accurate assumption to believe that everyone with the capability of running this stuff can do so without repercussion.
In the US, at least, anything you write IS copyrighted, by default. Including this paragraph. Copy at your own peril!