Having seen various boss situations from various perspectives, here is my $0.02 worth.
The manager of an engineering team has two jobs:
Organise the work of the team.
Represent the team to other areas of the company.
So you want to understand how good he is going to be at these things. Sound him out on the organisation by asking some open ended questions about how to manage projects. Like,
Marketing say if it isn't delivered in six months we'll lose half our sales, but your best estimate says it ships in a year. What do you do? (A: start trading features for ship time)
One of your developers comes to you enthusing about a new technology that could double our productivity at the cost of changing everything we do. What do you do? (A: explain the risks of new technology, then keep a watch out for reports of anyone else jumping first to see if he is right).
You hire a hotshot new engineer, but then he repeatedly asserts that the best way to get the job done is to leave him alone and not saddle him with cow orkers who can't keep up. What do you do? (A: Hand him a couple of difficult & complex assignments. If he succeeds, great. If not, explain to him that teamwork does actually help, and see about improving interpersonal skills. Wrong answer: "bring him down a peg".)
You are in a strategy meeting with senior management. Some favour Technology X. Others Technology Y. You know very little about either. The CEO tells you to come back in two weeks with a recommendation. What do you do? (A: First, find out if anyone on the team already knows about them. Then get a couple of people to dig up facts and brief you. Work with the team to put together a briefing for senior managers. Concentrate on business risks and productivity rather then technical coolness, but understand how the technology impacts these things.)
Finally, some general advice on interviewing. Remember that you are there to listen and evaluate. The candidate should be doing most of the talking. I've been in "interviews" which mostly consisted of a lecture by the interviewer. Avoid steering the candidate towards the right answer. Your purpose is not to get them to agree with you, its to find out what they know. Do challenge their views (even when you agree with them) to understand their depth of knowledge. If they start to flounder, just let them. Look for enough technical knowledge to hold an intelligent conversation with you, but then concentrate on people skills.
I ran ministumbler on my iPAQ and located a house over the road that was running an insecure WiFi network. I knocked on his door, introduced myself, and explained the potential problems he was facing. The fact that anyone could sit in a parked car and access his home computers was not something that had occured to him. Then I briefly explained some scenarios that ended with a search warrant. He got the point and enabled WEP.
You can make entangled copies of a photon, for instance, without having to violate any physical laws.
Really? How? And if so, how does this preserve the untapability of the link? Surely I could just amplify the photons and then divert half of them off to a reader, thereby (noisily) duplicating the data arriving at the receiver.
This isn't really my area of expertise so I'm not saying you are wrong, but I'd appreciate references.
You have to simultaneously break into the quantum and classical data transfer paths without them knowing.
As long as both ends are up, this is true. If one end goes down then there is a window of opportunity to splice. So just arrange for one end to go down, or for some obvious break in the cable to happen somewhere else, and then secretly install your tap-relay while they are fixing things. Or just get in before the link goes live.
If sender and reciever can authentificate via a public channel...
But if you can do that, you can do key exchange by the same mechanism. So why do you need QC? If you can't trust the authentication mechanism then you can't prove there is no man in the middle.
This is just snake oil. Quantum Cryptography (QC) is only good for point to point communications over short distances. You can't amplify the quantum signals, so the range is limited by the losses in the transmission medium. Long haul transmission requires that each relay decrypt and re-encrypt the data. So if you want to tap it you do it at the relays.
QC doesn't even prevent a man-in-the-middle attack. All you need to do is splice your tap in to the fibre (or whatever) and do QC with the two ends.
Quantum crypto is only useful over point to point for short distances because it relies on properties of photons that cannot be amplified (if they could be amplified then you could clone the signal and the security would be lost). Its also very very slow (kilobits per second at best). The way it is used is as a key distribution system. The heavy lifting of actually transmitting the data is done by ordinary crypto. So its no stronger than the ordinary crypto. The only thing in favour of quantum key distribution is that you can change the key very frequently.
But these days if you want to intercept data then cracking the crypto is one of the last avenues you would try anyway. Far easier to crack the end points, suborn a trusted employee or any of the other common attacks. Security is only as strong as the weakest link. Quantum crypto merely reinforces one of the strongest links.
This is the old "lump of labour" fallacy: the idea that there is only so much work to go around, so when giving a job to A means that B doesn't get one.
In fact there is a supply and demand curve: if labour is cheaper it means more people will be hired. If they produce the goods for less then people will buy more of them. And of course those Indian workers will get richer and want to buy consumer goods, which we can make and sell to them.
Also, if US companies don't or can't outsource then the goods they make will be more expensive than goods made by companies based in countries which do outsource, and so those US companies will go bust.
Canute thought he could order back the tide. People trying to stop the "export of jobs" are on pretty much the same trip.
(Actually, Canute didn't think he could order back the tide. He was just staging a scene to make his sycophantic counsellors look like the idiots they were. But thats beside the point).
Last time I was in The Good Guys (high end home theatre store) I saw a DVD/CD jukebox that held 300 (or was it 400?) disks and cost about the same in dollars. I think it was by Sony. So the simplest solution would be to buy three or four of those.
I used Jobserve in the UK. Although I didn't find a job from it, I did get some interviews.
The process seems a bit different to the US. Jobserve adverts come from recruitment agents. They are specialists who deal with the avalanche of inappropriate resumes in response to each advert and winnow it down to a manageable short list. These people also maintain their own resume databases, so a key part of job hunting is to get your resume on their databases. You do this by applying for jobs.
That said, it was a personal contact who got me my current job. Personal networks will always win in the job hunting game because hiring anyone is a risk, and knowing a prospective employee is the best way to reduce that risk. Thats why the inside candidate always wins, and there is nothing wrong with it.
I'd be interested in filing a complaint regarding their procedures... I am being FORCED to pay for a PRODUCT that I NEVER asked for nor implied that I wanted.
Hmmm. I skimmed through the Orders. There was something there about OEM discounts not being dependent on percentages of machines shipped with Windows. So if you are still being forced to pay the MS tax then make a complaint.
I co-wrote a paper which tackles exactly this question by looking at Sourceforge download and page hit statistics. We found a Pareto (aka Power Law) distribution of activity with a bottom end cut-off of around a 200-400 hits per month, and a large population of dead projects with no accesses. It seems that there is a critical mass required to sustain a project, and you have it.
As far as "success" goes, you do need to define success before you can decide if you have it. There is no single definition. Only you can decide if your project is meeting the goals you have set for it. I'd say that if you have a user community, active development and a roadmap for the future then your project is successful. One of the implications of a Pareto distribution is that the vast majority of projects are "small" in terms of users, developers and activity. So don't think you have failed just because you are not mentioned in the same breath as Apache, Samba and the Linux Kernel.
There are allegedly two categories of SCO code in the Linux kernel:
Code deliberately licensed by SCO under the GPL
Secret code copied into the GPL by a third party
Moglen seems to be claiming that since SCO has distributed Linux after discovering its secret code, and thereby accepted the GPL licensing of Linux, it must therefore have accepted that its secret code is also now licensed under the GPL. Its odd that Moglen never actually quotes the GPL itself, although he does cite it.
Obviously the licensing of certain code under the GPL by an organisation does not infect everything else published by that organisation. If the secret code exists in the kernel then SCO retains copyright and has not licensed anything.
The only clause that might "infect" the secret code with GPL-ness is the derivative works clause. Section 2 of the GPL states:
2. You may modify your copy or copies of the Program or any portion
of it, thus forming a work based on the Program, and copy and
distribute such modifications or work under the terms of Section 1
above, provided that you also meet all of these conditions:
[...]
b. You must cause any work that you distribute or publish, that in
whole or in part contains or is derived from the Program or any
part thereof, to be licensed as a whole at no charge to all third
parties under the terms of this License.
So if SCO has modified a stock version of the kernel to create a derivative work then it automatically licenses everything in that new derived work, and all works subsequently derived from it, under the GPL. In theory this applies whether a human being at SCO spotted the secret code or not, although I'm not at all sure that such an argument would stand up to the legal principle that you can only agree to something if you consciously know you are agreeing to it. However, having modified the kernel (creating a derivative work) and then distributed that derivative work, or one further derived from it, knowing that it contains the secret code, it does seem that SCO has indeed licensed the secret code under the GPL.
Moglen states that SCO has dontated chunks of code the Linux kernel. Torvalds has stated that it will be very easy to find out who contributed what in the past. So, can we find out exactly which bits of code were granted by SCO, and if it did indeed create a derived work that would trigger section 2b of the GPL?
The 80% of people from out of town are a potential source of funding, especially as they will want to use the computers to check their email when most other people are at work.
Set up a membership scheme that gives locals cheap access to the whole works, but charges visitors more for cybercafe facilities. Then get your business customers to give you free advertising pitched at visitors.
(Or to be more precise, could someone in Washington DC go and look at it?)
If so, could someone please take a look and note down some search strings to grep the Linux kernel for? This could be the way around the NDA to figure out what bits of Linux they are going to claim to own.
The big problem with selling content is that the customer can't inspect it before the sale, and can't effectively return it after the sale.
(Incidentally, have you thought about the rate of chargebacks you will get from people who download the music and then claim it wasn't them?)
This introduces a risk for the customer: what if I don't like it. You can reduce this risk in two ways:
Provide low-quality samples from the tracks.
Provide some kind of "reputation" system akin to those provided by Amazon, so that people can easily find music that people with similar tastes also like.
Its always a danger sign when people complain that the official process is counterproductive, because they are usually right.
The solution to this is to fix the process, not the people. In this case your "quick and dirty" approach has been shown to work and needs to be integrated with the official processes. Write down the criteria for projects where this process should or should not be used. State the limitations, costs and risks clearly. In particular, it sounds like you have difficulty getting resources to go back and do it right, so put that into the process. Then get your shiny new process approved by the process police and inserted into the official manual.
There are two kinds of organisations that have process manuals and make sure they are followed. One is a mature organisation of CMM level 2 or above. The other is an immature organisation at level -1 or below, in which counterproductive processes are rigidly enforced. The test that distinguishes them is what happens when someone proposes an improvement to the process.
Legally (and practically) you have to know you are doing something before you can be said to have decided to do it.
In this case, it seems likely that SCO will say that they were unaware of their own IP being in Linux, and hence had not made any decision to license it under the GPL even though they were distributing it. Once they became aware of it they stopped the distribution.
The letter does not change this situation. SCO has contractual commitments to people who bought its Linux distribution. This leads to the odd (but perfectly consistent) situation where SCO's IP was aquired without a licence, but SCO is still legally required to support it because there is no way it can fail to support it without being in breach of contract.
If I buy the new Harry Potter book, for instance, can't I assume I have a license to read it?
Under normal circumstances yes. But if J K Rowling or her publishers sold you a PC that inadvertantly had a copy of the book on its hard drive then no, you would have no right to read it. This is a much closer analogy than just buying an ordinary book.
When you have a value chain, such as the one that goes into a PC (processor, mobo, memory, video card, OS etc) then there is a specific amount of money available per final unit sold. If you are in that chain then you want as much of that money as possible. The more that the rest of the chain takes, the less there is available for you. So you, along with everybody else in that chain, want two things:
You want your component to be a high-priced proprietary item with no alternatives.
You want everybody else's components to be low value commodities so that their prices go down and their profit margins get squeezed.
In the case of Intel and MS, both Intel and MS want there to be active competition for the other. Hence MS will support competitors to Intel in order to drive down CPU prices, and Intel will support Linux in order to drive down OS prices. Both will support a multiplicity of mobo makers, hard drive makers, video chipset makers and anyone else in order to keep those areas as low-priced commodities. I suspect that the current duopily in the graphics chipset market is causing both of them some concern. If either Nvidia or ATI win the bulk of the market then they will be able to start charging proprietary prices (to some extent they already are at the higher end) and thereby take away money from both Intel and MS. From the POV of ATI and Nvidia of course they want lots of competition for both Intel and MS, which helps to explain why both of them are taking the trouble to support Linux when the Linux share of the desktop graphics market is still under 1%.
Slashdot Mirror
The manager of an engineering team has two jobs:
So you want to understand how good he is going to be at these things. Sound him out on the organisation by asking some open ended questions about how to manage projects. Like,
Finally, some general advice on interviewing. Remember that you are there to listen and evaluate. The candidate should be doing most of the talking. I've been in "interviews" which mostly consisted of a lecture by the interviewer. Avoid steering the candidate towards the right answer. Your purpose is not to get them to agree with you, its to find out what they know. Do challenge their views (even when you agree with them) to understand their depth of knowledge. If they start to flounder, just let them. Look for enough technical knowledge to hold an intelligent conversation with you, but then concentrate on people skills.
Paul.
Paul.
Paul.
Really? How? And if so, how does this preserve the untapability of the link? Surely I could just amplify the photons and then divert half of them off to a reader, thereby (noisily) duplicating the data arriving at the receiver.
This isn't really my area of expertise so I'm not saying you are wrong, but I'd appreciate references.
Paul.
As long as both ends are up, this is true. If one end goes down then there is a window of opportunity to splice. So just arrange for one end to go down, or for some obvious break in the cable to happen somewhere else, and then secretly install your tap-relay while they are fixing things. Or just get in before the link goes live.
Paul.
But if you can do that, you can do key exchange by the same mechanism. So why do you need QC? If you can't trust the authentication mechanism then you can't prove there is no man in the middle.
Paul
QC doesn't even prevent a man-in-the-middle attack. All you need to do is splice your tap in to the fibre (or whatever) and do QC with the two ends.
Paul.
If you can't beat 'em, poach 'em
Paul.
But these days if you want to intercept data then cracking the crypto is one of the last avenues you would try anyway. Far easier to crack the end points, suborn a trusted employee or any of the other common attacks. Security is only as strong as the weakest link. Quantum crypto merely reinforces one of the strongest links.
In fact there is a supply and demand curve: if labour is cheaper it means more people will be hired. If they produce the goods for less then people will buy more of them. And of course those Indian workers will get richer and want to buy consumer goods, which we can make and sell to them.
Also, if US companies don't or can't outsource then the goods they make will be more expensive than goods made by companies based in countries which do outsource, and so those US companies will go bust.
Canute thought he could order back the tide. People trying to stop the "export of jobs" are on pretty much the same trip.
(Actually, Canute didn't think he could order back the tide. He was just staging a scene to make his sycophantic counsellors look like the idiots they were. But thats beside the point).
Ever hear of the "robber barons"? The anti-trust laws in the US were created in response to these people.
Paul.
Last time I was in The Good Guys (high end home theatre store) I saw a DVD/CD jukebox that held 300 (or was it 400?) disks and cost about the same in dollars. I think it was by Sony. So the simplest solution would be to buy three or four of those.
Paul.
I used Jobserve in the UK. Although I didn't find a job from it, I did get some interviews.
The process seems a bit different to the US. Jobserve adverts come from recruitment agents. They are specialists who deal with the avalanche of inappropriate resumes in response to each advert and winnow it down to a manageable short list. These people also maintain their own resume databases, so a key part of job hunting is to get your resume on their databases. You do this by applying for jobs.
That said, it was a personal contact who got me my current job. Personal networks will always win in the job hunting game because hiring anyone is a risk, and knowing a prospective employee is the best way to reduce that risk. Thats why the inside candidate always wins, and there is nothing wrong with it.
Hmmm. I skimmed through the Orders. There was something there about OEM discounts not being dependent on percentages of machines shipped with Windows. So if you are still being forced to pay the MS tax then make a complaint.
Paul.
As far as "success" goes, you do need to define success before you can decide if you have it. There is no single definition. Only you can decide if your project is meeting the goals you have set for it. I'd say that if you have a user community, active development and a roadmap for the future then your project is successful. One of the implications of a Pareto distribution is that the vast majority of projects are "small" in terms of users, developers and activity. So don't think you have failed just because you are not mentioned in the same breath as Apache, Samba and the Linux Kernel.
Paul.
Moglen brings up trade secrets and patents to dispose of them, leaving copyrights. It is copyright that is the main subject of his paper.
- Code deliberately licensed by SCO under the GPL
- Secret code copied into the GPL by a third party
Moglen seems to be claiming that since SCO has distributed Linux after discovering its secret code, and thereby accepted the GPL licensing of Linux, it must therefore have accepted that its secret code is also now licensed under the GPL. Its odd that Moglen never actually quotes the GPL itself, although he does cite it.Obviously the licensing of certain code under the GPL by an organisation does not infect everything else published by that organisation. If the secret code exists in the kernel then SCO retains copyright and has not licensed anything.
The only clause that might "infect" the secret code with GPL-ness is the derivative works clause. Section 2 of the GPL states:
So if SCO has modified a stock version of the kernel to create a derivative work then it automatically licenses everything in that new derived work, and all works subsequently derived from it, under the GPL. In theory this applies whether a human being at SCO spotted the secret code or not, although I'm not at all sure that such an argument would stand up to the legal principle that you can only agree to something if you consciously know you are agreeing to it. However, having modified the kernel (creating a derivative work) and then distributed that derivative work, or one further derived from it, knowing that it contains the secret code, it does seem that SCO has indeed licensed the secret code under the GPL.
Moglen states that SCO has dontated chunks of code the Linux kernel. Torvalds has stated that it will be very easy to find out who contributed what in the past. So, can we find out exactly which bits of code were granted by SCO, and if it did indeed create a derived work that would trigger section 2b of the GPL?
Paul.
Set up a membership scheme that gives locals cheap access to the whole works, but charges visitors more for cybercafe facilities. Then get your business customers to give you free advertising pitched at visitors.
Paul.
(Or to be more precise, could someone in Washington DC go and look at it?)
If so, could someone please take a look and note down some search strings to grep the Linux kernel for? This could be the way around the NDA to figure out what bits of Linux they are going to claim to own.
Paul.
(Incidentally, have you thought about the rate of chargebacks you will get from people who download the music and then claim it wasn't them?)
This introduces a risk for the customer: what if I don't like it. You can reduce this risk in two ways:
Good luck.
Paul.
How much does this actually happen? Are there any figures tracing this kind of criminal re-investment?
Paul.
The solution to this is to fix the process, not the people. In this case your "quick and dirty" approach has been shown to work and needs to be integrated with the official processes. Write down the criteria for projects where this process should or should not be used. State the limitations, costs and risks clearly. In particular, it sounds like you have difficulty getting resources to go back and do it right, so put that into the process. Then get your shiny new process approved by the process police and inserted into the official manual.
There are two kinds of organisations that have process manuals and make sure they are followed. One is a mature organisation of CMM level 2 or above. The other is an immature organisation at level -1 or below, in which counterproductive processes are rigidly enforced. The test that distinguishes them is what happens when someone proposes an improvement to the process.
Good luck,
Paul.
In this case, it seems likely that SCO will say that they were unaware of their own IP being in Linux, and hence had not made any decision to license it under the GPL even though they were distributing it. Once they became aware of it they stopped the distribution.
The letter does not change this situation. SCO has contractual commitments to people who bought its Linux distribution. This leads to the odd (but perfectly consistent) situation where SCO's IP was aquired without a licence, but SCO is still legally required to support it because there is no way it can fail to support it without being in breach of contract.
If I buy the new Harry Potter book, for instance, can't I assume I have a license to read it?
Under normal circumstances yes. But if J K Rowling or her publishers sold you a PC that inadvertantly had a copy of the book on its hard drive then no, you would have no right to read it. This is a much closer analogy than just buying an ordinary book.
Paul.
In the case of Intel and MS, both Intel and MS want there to be active competition for the other. Hence MS will support competitors to Intel in order to drive down CPU prices, and Intel will support Linux in order to drive down OS prices. Both will support a multiplicity of mobo makers, hard drive makers, video chipset makers and anyone else in order to keep those areas as low-priced commodities. I suspect that the current duopily in the graphics chipset market is causing both of them some concern. If either Nvidia or ATI win the bulk of the market then they will be able to start charging proprietary prices (to some extent they already are at the higher end) and thereby take away money from both Intel and MS. From the POV of ATI and Nvidia of course they want lots of competition for both Intel and MS, which helps to explain why both of them are taking the trouble to support Linux when the Linux share of the desktop graphics market is still under 1%.
Paul.
Paul.