All the article demonstrates is that LexisNexis knows womens' maiden names. It demonstrates nothing about outing undercover agents. The only reason the reporter knew to even look for Wilson's wife's name was because "two officials" (allegedly Rove and someone else) leaked the fact that his wife worked for the CIA. That was the source of the privacy/security breach, not Google or LexisNexis.
And in any case, a maiden name isn't exactly private information - many acquaintances of a person have access to it, as the woman has used the name publicly for many years. (There are organizations foolish enough to use this as a security-screening question, but the insecurity of this practice is not new to the information age).
Neither is your address private information - addresses have been publically available for free in phone books for decades.
If anything, the real shocker (besides the leak itself) should be that the CIA had an undercover agent using as cover their maiden name. Assuming that the CIA is not run by imcompetents, I'd say they must not have cared all that much about her cover if that was the only obfuscation they chose.
The real problem here is not that Mozilla is releasing security fixes too quickly, or that the distros aren't keeping up.
The real problem is that a Linux application needs to be modified in some way by the operating system vendor before end-users of that operating system can use it. Think about that for a minute. When's the last time you had to go through Microsoft to download the latest copy of a 3rd-party application?
One of the selling points of OSS development has always been its decentralized nature. But here we are creating a centralized, artificial bottleneck by requiring that applications be customized by the operating system vendor before it can be used on that system. Talk about inefficient.
There's no reason why the application vendor should be exposed to differences in distributions. It's poor encapsulation, from a software engineering perspective, and essentially means that "Linux" is not a platform you can develop to. RedHat's a platform, SuSE's a platform, and there a million other Linux-based platforms, but no one "Linux platform".
This sort of thing hurts everyone. End-users don't have the ease of use and speed of security updates they could with a common platform. Application vendors have to wait for the OS vendor to repackage their application before it'll work on that platform. Distro vendors have this huge recurring workload of having to repackage applications.
Why don't the distros just provide a common interface that application vendors can use to for installation? Hiding the distribution-specific differences behind an interface would seem to make everyone's jobs easier.
If you don't put in the necessary time [...] to properly document your code, you'll wind up spending a lot of time trying to figure out just what you did and why
The corollary to this is the need to maintain existing comments when the code is changed. Misleading/outdated comments can sometimes be worse than none at all.
proper documentation is professional courtesy
I couldn't agree more. Good documentation gives you context and insight into the motivation of a past developer, which can be priceless when trying to understand unfamiliar code. Good variable names can give you the "how" the code is implemented, but good comments give you the "why".
I'd be more worried about what the agreement says about what you're allowed to do AFTER you move on from that place.
Exactly. A BIG one to worry about is non-compete clauses.
When I was in school, a company made me an internship offer, but their proposed contract included a 1-year non-compete agreement. This doesn't sound so bad (you're in school for a year and then looking for the next internship or full-time job)... until you realize that your next job will start in only 9 months from the END of the other.
Constraining one's choice of full-time employment based upon a 3-month internship is probably not wise, since the field of a company's "competitors" can be quite broad. I walked away from the internship, had a fairly dull job for that summer, but was later glad I did. While I missed out on a potentially cool internship, I didn't have to worry about legal considerations when I was job hunting during a recession.
Loaning money to yourself is not an investment. It's Enron-style accounting; a sleight-of-hand to disguise the fact that Congress spent the money intended for our senior citizens' retirements.
The government takes money from the Social Security trust fund, spends it, and gives itself (SS) an IOU. Sure, the IOU is a Treasury bond that promises interest. But since the government is the party that *pays* the interest, as well as receiving it, there's no actual gain. And it's even worse - it's not even a zero-growth savings, because they spent the money. So all those IOUs in the SS fund are really just a big pile of government debt. When the real money in the trust fund starts to run out in few decades, look out. The government will be forced to either raise taxes or cut benefits drastically.
On the other hand, if the politicians take their heads out of the sand and start to do something about it now, maybe we'll have a chance at saving Social Security.
The major problem is that Congress has shown itself incapable of discipline (or integrity!) by its continual raids on the trust fund. I have no reason to believe future politicians will be any more responsible. Personal accounts seem to be the only way to force politicians to get money for non-SS things the old-fashioned way - through taxes with associated political consequences, rather than through on-the-sly theft from the trust fund. And preventing theft from the trust fund is the only way we'll ensure Social Security is there for us when we retire.
Opponents of accounts have legitimate concerns about whether individuals would invest wisely, what to do if they don't, etc. Maybe the answer is limitations to "safe" investments, maybe it's having all SS accounts managed professionally, I don't know. But we should be debating exactly those questions, and how to fix them, not pretending (as the article does) that the current system is in any way either an investment or sustainable.
"any real-time Sys Admin knows that the best solution is to give users what rights they need to work."
That's exactly my point - being able to try and use new tools on your own is a fundamental aspect of the "rights they need to work". Particularly in the field of software development, where the available tools are continuously changing and improving.
Dont make them Gods in an environment so they can have Webshots or that rare unecessary upgrade.
I'm not arguing developers should be made Gods on their machine. As a developer, I don't care about or want privileges to upgrade the OS, install new hardware, change firewall settings, or any of a million other sysadmin tasks that need "God" privileges to perform. I'm asking for the ability to install and use the application software of my choice so I can be as productive as possible at my job. In a reasonable environment, that should not require "God" privileges.
I would also argue that useful upgrades are neither unnecessary nor always rare, and that in any case, the developer is the person who is in the best position to determine what is "necessary" to his or her job.
Finally, with regard to the Self Proclaimed Guru screwing up their PC or network: can it happen? Sure. It's a risk that needs to be managed. But risk avoidance isn't the same as risk management. One way to manage that risk in a software development shop: give the developers a mandatory training session on Dos & Don'ts for installing software, and monitor their machines. If they ignored the training and screwed stuff up, you have a policy in which they get educated on their mistake, and in which repeated violations lead to a revokation of privileges.
A closer analogy would be that the machinist has a better wrench out in his truck but isn't allowed to just bring it in the building and use it. First he must put in a call-ticket, then hope that the helpdesk is willing to send somebody out to his truck, carry the new wrench inside, and put it in his working area. Because "it's not the machinist's job" to do that stuff.
The point is that centralizing common and simple tasks wastes everyone's time - the support guy and machinist alike.
Helpdesk is probably understaffed, and almost certainly has (at least from their perspective) more important things to do. Meanwhile, the machinist is stuck with an inferior tool until he can work the bureaucracy to get the new wrench in.
The company loses too because it's using inferior tools, simply because the guys who use them aren't empowered to change their work environment.
And not only is it extraordinarily difficult to bring in new but known-to-be-better tools (sometimes even free ones!), but forget trying to experiment with a tool to find out if it's better. Try convincing an overworked support guy that you really need this application installed because you want to try it out. You'll see snowballs in hell before that tool gets installed. Not through any fault of the support guy - he's just being rational and allocating his limited time to higher priorities. But the system is clearly flawed.
In contrast, if the developer could admin his own machine, he could install something, try it out, and if it's helpful other developers could start using it too.
Now is it possible that the developer could accidentally install malware if he has admin? Sure. But that's why Microsoft monitors their network - they can catch and correct mistakes that happen. They no longer handicap the developers, and IT doesn't have to babysit on simple things like application installs. The company reaps the productivity awards accordingly.
Car manufacturers and other corporations learned years ago that giving the person closest to the problem the power to solve it lets them avoid bottlenecks and reap massive productivity gains. Somehow, the conventional wisdom on IT management hasn't quite caught up yet with the rest of the management world.
1. The election will be a close contest between the two "major" parties, with Nader a distant third (almost guaranteed) 2. Nader supporters will vote for Nader unless one of the major candidates comes close enough to the Nader position (plausible) 3. The goal of the Nader campaign is primarily about achieving Nader-like policy (possible), rather than winning the election (which would be nearly impossible)
Then it might make good sense for Nader to run, and Nader voters for to vote for him unless a major candidate adopts a more Nader-like position. Even if he doesn't have a chance of winning.
If the Democrats know they need Nader voters in order to win the election, they could be forced to align their policy more closely with his in order to siphon away a (small but potentially decisive) number of votes. Of course, this makes the (big) assumption that moving closer to the Nader position wouldn't alienate more moderate voters, thus negating the benefit.
This is basically a higher-risk but higher-reward strategy for the Nader constituency. On the one hand, if the Democrats don't adjust leftward, then there's the risk that Nader votes helped elect the Republican. But if the Nader folks vote Democrat without demanding anything for it, the Democrats can take their votes for granted. This would mean a less liberal Democrat position, because the logical thing for Democrats to do in that situation is to swing less liberal in order to pick up more swing votes.
IRV has its share of problems, though. According to this Approval Voting site, IRV only helps avoid the spoiler effect when there are exactly two viable candidates. Once a third candidate becomes viable too, you're back to the same old problem.
True. In essence Paypal is a money delivery service - you give them money, they deliver it to someone you specify.
As a result, it seems to me that Paypal has a moral (and maybe legal, IANAL) obligation to safeguard that money while it's in Paypal's possession. And they should be responsible for ensuring that the person they deliver the money to is indeed the person you specified should receive it.
OTOH, Paypal should not be responsible for anything more than this. If you decide to send someone money, and it turns out you were scammed, well that's not Paypal's fault.
In the AbiWord case, it sure looks like it was a case of the money being outright stolen from the Paypal account. Paypal should refund the money to AbiWord (which really ought to be covered by insurance, anyway. Insurance is a basic part of running any business). And they should certainly assist the victim in launching a criminal investigation for wire fraud.
I don't think it's fair to place the blame entirely on "lazy developers".
As I see it, there are two possibilities when a bank site doesn't work with non-IE browsers:
1. The bank wanted a solution that would work with all browsers, but the developer cut corners and didn't provide it. 2. The bank didn't care.
For #2, I think it's safe to say the blame lies solely with the bank.
For #1, it seems the blame is largely with the developers. After all, the site's ability to work with all browsers was either explicitly stated, or it was implied. There's no reason an ordinary person would think "I want you to build my website" would be interpreted as "I want you to build a website that only some of my customers can use". Unless the developer explicitly states that their proposal is limited to IE, the expectation is (rightfully) that there is no such limitation.
At the same time, though, any organization contracting out such a significant job has a responsibility to exercise some due diligence. Especially a financial organization, due to the need for security. They ought to do enough research (either themselves, or hire a consultant) to know how to discriminate between competing bids. And they ought to ensure before accepting a bid that the developer truly understands their requirements, and that all requirements are in the contract. If they do all that, and the developer doesn't provide everything they said they would, that's breach of contract. If the bank doesn't do its due diligence, then it has to accept a share of the blame for having a half-assed website.
FWIW, Bank of America's site seems to work fine with Mozilla.
The case in question is not frivalous. MS is correct. The mod chips are illegal under current law. They are circumvention devices. They contain copyrighted code. The names probably even infringe on trademark.
That's far from certain or correct:
A) Whether the mod chips are "circumvention devices" is certainly matter a debate. Witness a recent Sony case in Australia (whose law is similar to the U.S.'s DMCA), which found the chips not to be a "circumvention device" under the law. And thus, not illegal.
B) There's a very good chance the chips do not contain any code that is copyrighted by MS. They don't need to. They might reverse-engineer some technical information, and use that to create their own code, but that is not the same as copying MS code, and does not infringe on any MS copyrights.
C) The names may infringe on trademarks, but that does not make the product itself illegal. It just makes selling it under that name illegal - the company could still sell the product under a non-trademark-infringing name.
Yes. That's how courts work. You sue or are sued. A judge decides.
The alternative is no courts, just executive authority to arrest/imprision/confiscate. That has a history of working really well. You think corporations are too powerful now?
Judges toss lawsuits everyday of the week. Its a routine part of the legal system.
I think you're missing the larger, implicit point of the previous poster's comment. It's not that we shouldn't have a judicial system, it's that the current system has a significant bias towards those with wealth. I.e. someone with wealth can afford to file a suit they know is without merit, because it will cost the target of the suit legal fees. If the target doesn't have the money for a lawyer, the wealthy (corporation or individual) essentially wins by default because the target has to stop doing what they're doing, regardless of if it's actually legal. Sure, the suit will eventually get tossed, but in the meantime those bills sure add up fast. Many people can't afford that.
The solution isn't to scrap the legal/judicial system, it's to improve it. How to do that is an interesting and complex question. It's not clear how to easily discourage this sort of legal skirmishing without discouraging legitimate claims as well.
Taking away essential freedoms does not guarantee security. In fact, reduced freedom can often reduce security. If we had a police state, sure we would have a somewhat easier time nailing terrorists. But how secure would you really be? You've just traded the occasional terrorist for an ever-present government tyrant.
It is our freedoms that *provide* our security. Restrictions on governmental/police powers promote the fairness and honesty that enable all citizens to be safe. This is why we require warrants before allowing the government to spy on you or search your property. This is why the police have to have probable cause to arrest you, rather than because "he looked like he was up to no good". If we give up these kind of freedoms in an attempt to fight terrorists, we'll only be less secure. And the terrorists will have won.
It's interesting to note that of all the countries in the world, Americans are probably the safest. And we're the most free. Coincidence? I don't think so.
I'm all for giving the government new tools to help in the fight against terrorism. Reform wiretap laws to have wiretaps be on a per-person, not per-phone basis. Expand the ability to wiretap in cyberspace to match the equivalent in phonetap law. These will help fight terrorism without destroying our freedoms.
Other proposals do the opposite. They remove freedoms without helping the terrorist fight. Mandated encryption backdoors or bans on encryption are a good example of this. While they would appear to help, they really wouldn't. Terrorists would just get their crypto from abroad, while ordinary citizens are now more susceptible to the snooping of cr/hackers and the government.
What is really needed is a cool-headed assessment of what we can do to promote security without jeopardizing our freedom and our way of life. Decreasing our freedoms will only decrease our security in the long term. Let's make ourselves more secure, not less.
I think crypto-guy Bruce Schneier put it well when he said:
"The ideals we uphold during a crisis define who we are. Freedom and liberty have a price, and that price is constant vigilance so it not be taken from us in the name of security. Ben Franklin said something that was often repeated during the American Revolutionary War: 'They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.' It is no less true today."
Yes, I've had both types of managers, but what you are largely talking about is people skills.
Exactly. People skills. Hence, skilled labor.:-)
But most of this stuff you should have learned in kindergarten.
Partially true. Certain basics you should've learned in kindergarten, but I'm continually amazed at how many adults haven't mastered basic manners. Plus, there's a lot more than kindergarten skills that go into good managers. Motivating people, communicating complex concepts in ways that people can understand, etc.
once a manager has mastered the soft issues, he's pretty much done
But that's the thing - he really isn't done. Like any other skills, effective people skills require that you keep using those skills to keep them in shape. It's kinda like programming - once you've mastered the basic concepts of programming, you could say that you're "pretty much done". But the specific skills - say language X - you need to keep current on or you're not going to be effective. Similarly, managers must keep current on (and the best continually *improve* on) their skills - being able to motivate their team, communicate effectively between their workers and higher management (and maybe customers), and keep the group working smoothly. These may very well be "soft" skills, but they are skills in every sense of the word.
You are right that the "Cope Morphing" does consume some CPU cycles when it's first performed, though it is cached so the performance hit isn't excessive.
One major benefit however is that you drastically reduce the amount of silicon you need to build your chip. In some of the modern CPUs like the PIII, instruction decoding (the very thing Transmeta is doing in their Code Morphing) can take up half your silicon. That's a lot of savings in power, heat dissipation, and cost.
Transmeta took this in one logical direction and created a mobile CPU. This makes sense, and is a good way to get into a market where the competition from Intel/AMD wasn't as formidable. But here's another application: instead of just throwing out that 50% of silicon real estate, put in more integer and floating point units, maybe increase the cache. That 50% will buy you a lot of extra processing power.
Suddenly, they'll have a powerhouse chip that may very well outperform Intel and AMD's offerings at a comparable power/heat/cost. The hardware changes would be relatively simple, and would require modest changes to the Code Morphing software to make use of the extra hardware units. Transmeta could do this without much difficulty.
Will they? Not until they get themselves more firmly established in the mobile market. But once they have the financial muscle to take on Intel/AMD on their home turf, I think they will. The profit margins on desktop/server chips too high to pass up.
Let me share what I've seen at my school with ECE vs. CS majors, and their experiences with hardware/architecture.
I expect that which major - ECE vs CS - you choose will depend largely upon how the individual school structures their programs. At Carnegie Mellon, where I am currently a senior, those interested in hardware and architecture design would do best to major in ECE, as that is where much more emphasis/coursework is to be had in those areas.
Keep in mind that if you try hard enough, you can probably get away with being a CS major and taking the hardware courses through the ECE Dept, it's just harder due to prerequisites. Similarly, you can be an ECE major and take the stereotypically CS courses. Which says something about the flexibility about both programs here (both programs are among the best in the nation) but I don't know how flexible other schools may be with that. YMMV.
The reason, it seems to me, that there is debate about which is better for a given interest is because there is significant overlap between the two fields. People in both areas have to know the basics of hardware and software, just because each has to interact with the other. Which aspect you want to specialize in will probably determine your choice of major. I chose to major in ECE because I didn't know which path I wanted to take; it's looking now more like software, so I'm taking a bunch of CS classes, but I find my hardware background to be very valuable in my software work as well. I don't think I'd have been as well prepared if I had started in CS and tried to migrate towards hardware.
So my advice to someone choosing a major:
1. Check how your school of choice structures their program. Maybe even try to contact faculty at the school, and ask them questions. This more than anything will help you figure out which would best match your interests.
2. If that doesn't give enough info to make your choice, go into CE. It will give you a broad foundation from which you can easily migrate to CS if you later find that's what you want.
The system being flawed is not a justification for the abuse of that flaw by individuals/entities (such as, in this case, David Powell/CCS). Just because the system allows something doesn't mean it's right.
If a website has poor security, does this make it okay to rip off credit card numbers from the site?
His abuse of the legal system to force huge legal bills on people who haven't been convicted of a single thing to me seems to be a simple case of the richer party bullying the poorer one. It's to the point where acual guilt or innocence isn't really the issue, it's "how much money can we get out of this guy?".
I'm also from NY, and knowing people who have gone through the NY court system about a non-compete agreement, one warning to those who are thinking along the lines of "it isn't enforceable" etc.
Whether or not it is enforceable is NOT necessarily your biggest problem. If you sign such an agreement, later leave that company, and they claim a violation of the non-compete (even if you didn't ACTUALLY violate anything), THE BURDEN IS ON YOU to prove that the contract is not enforceable. This means that you have the great expense of hiring a lawyer to prove this in court, even if you win. Also consider that these suits can be dragged out by your former employer for many years. While the suit is unresolved, keep in mind that the suit may have consequences on who may be willing to hire you. Or if you started your own firm, it may scare off potential investors. All of this, even if the company suing you is utterly wrong.
As far as the legality of the non-competes go, from my understanding (IANAL) they are legal as long as they fall within certain constraints specified by the law. For example, they must have a limited geographic area - a company can't make you sign a noncompete that covers the whole world. Maybe they could say you can't work for a competitor west of the Mississippi (arbitrary, yes, and in some ways illogical considering the global economy, but such is the law). The contract cannot preclude you from being able to make a living (ie if you're a programmer it can't preclude you from working for any other software firm, though they may be able to specify certain subsets of software firms as off-limits).
If you are presented with a non-compete as a condition of employment, try to see if you can get them to hire you without it. If you know other employees of the company, find out if they had to sign. If they did not, this should help your case.
Also note that non-disclosure is a different beast than non-compete. Non-disclosure is much more acceptable, you aren't precluded from working for a competitor, you just can't share any proprietary information with your new employer. While this can be a tricky area (some companies seem to think that anything is their proprietary info, even if it's something that clearly is not - such as your general C++ or Perl skills - that sort of arrogance tends to appear particularly in those cases where the employer provided training)
My biggest advice - TALK TO A LAWYER BEFORE SIGNING ANY EMPLOYMENT AGREEMENT. It may save you a lot of stress down the road. Also try to get a lawyer who is familiar with the employment practices of the industry you're in - they can give you information about how common things like requiring non-competes are in your specific industry.
And again, talk to a lawyer. You don't want your career to get fouled up over a lawsuit you could have prevented with some prior diligence.
>Do you understand the need for a manual recount now?
The problem is that with every additional recount you do (manually OR by machine), you introduce further error into the count. This is because with a punchcard system such as they're using in Florida, moving the punchcards around may break off chads - which may or may not have been actually punched through by the voter (they may have only been indented, or "dimpled"). It may have been that they were about to vote for the candidate, dimpling the chad, and then didn't vote for anyone. Now during the recount, the chad falls out and it's counted as a vote the voter didn't intend. Or they may have been about to vote for a candidate, and then voted for another - in which case if in the next recount the dimpled/pregnant/whatever chad for the almost-voted-for candidiate falls off, as commonly happens with these punchcards, then that vote will be invalidated because it now looks like they voted for two presidential candidates.
And there's no way for us to know which of these situations may or may not have occurred with each ballot.
This is why there were different results in each of the recounts by machine, because sending them through the machine causes more chads to fall off (sending them through the hands of human counters would have much the same effect, as they get flexed and moved around, etc). Which is also why a manual recount isn't going to improve your accuracy, because the process of recounting itself is changing what the ballots are showing. Even if you ignore the potential for bias among human counters, the ballots they're trying to count are no longer going to show the same thing as they did on election night due to the physical limitations of the cards.
I personally would like to see more counties moving towards electronic systems such as the touchscreen-based ones used in several counties nationally. They look much like an ATM, and people have found them very easy to use. This eliminates this ridiculous situation of having to look at chads, and somehow try to divine the intent of the voter from how much a chad is hanging off, or how much it's dimpled, etc.
The top 1% of the US population pays 35% of the federal income tax. The top 5% pays 54% of the federal income tax. (Source: Wall Street Journal, dead tree version from about a week ago, or I'd give a link)
A large chunk of the population (I don't remember exact percentage, I think about one-third) doesn't pay ANY federal income tax. So of course, a tax cut isn't going to help those people - but that's perfectly fine, since they're paying NOTHING as it is. Further, I see no problem with a larger dollar amount of refund going to those who paid more taxes - we have a surplus, which means everyone overpaid, which means those who overpaid more should get more back (in proportion to how much they overpaid). Seems only fair.
Slashdot Mirror
All the article demonstrates is that LexisNexis knows womens' maiden names. It demonstrates nothing about outing undercover agents. The only reason the reporter knew to even look for Wilson's wife's name was because "two officials" (allegedly Rove and someone else) leaked the fact that his wife worked for the CIA. That was the source of the privacy/security breach, not Google or LexisNexis.
And in any case, a maiden name isn't exactly private information - many acquaintances of a person have access to it, as the woman has used the name publicly for many years. (There are organizations foolish enough to use this as a security-screening question, but the insecurity of this practice is not new to the information age).
Neither is your address private information - addresses have been publically available for free in phone books for decades.
If anything, the real shocker (besides the leak itself) should be that the CIA had an undercover agent using as cover their maiden name. Assuming that the CIA is not run by imcompetents, I'd say they must not have cared all that much about her cover if that was the only obfuscation they chose.
It's not $65/hour in wages, but in combined wages and benefits. Health care, 401K matching, etc. adds more than you'd think.
The real problem here is not that Mozilla is releasing security fixes too quickly, or that the distros aren't keeping up.
The real problem is that a Linux application needs to be modified in some way by the operating system vendor before end-users of that operating system can use it. Think about that for a minute. When's the last time you had to go through Microsoft to download the latest copy of a 3rd-party application?
One of the selling points of OSS development has always been its decentralized nature. But here we are creating a centralized, artificial bottleneck by requiring that applications be customized by the operating system vendor before it can be used on that system. Talk about inefficient.
There's no reason why the application vendor should be exposed to differences in distributions. It's poor encapsulation, from a software engineering perspective, and essentially means that "Linux" is not a platform you can develop to. RedHat's a platform, SuSE's a platform, and there a million other Linux-based platforms, but no one "Linux platform".
This sort of thing hurts everyone. End-users don't have the ease of use and speed of security updates they could with a common platform. Application vendors have to wait for the OS vendor to repackage their application before it'll work on that platform. Distro vendors have this huge recurring workload of having to repackage applications.
Why don't the distros just provide a common interface that application vendors can use to for installation? Hiding the distribution-specific differences behind an interface would seem to make everyone's jobs easier.
If you don't put in the necessary time [...] to properly document your code, you'll wind up spending a lot of time trying to figure out just what you did and why
The corollary to this is the need to maintain existing comments when the code is changed. Misleading/outdated comments can sometimes be worse than none at all.
proper documentation is professional courtesy
I couldn't agree more. Good documentation gives you context and insight into the motivation of a past developer, which can be priceless when trying to understand unfamiliar code. Good variable names can give you the "how" the code is implemented, but good comments give you the "why".
I'd be more worried about what the agreement says about what you're allowed to do AFTER you move on from that place.
Exactly. A BIG one to worry about is non-compete clauses.
When I was in school, a company made me an internship offer, but their proposed contract included a 1-year non-compete agreement. This doesn't sound so bad (you're in school for a year and then looking for the next internship or full-time job)... until you realize that your next job will start in only 9 months from the END of the other.
Constraining one's choice of full-time employment based upon a 3-month internship is probably not wise, since the field of a company's "competitors" can be quite broad. I walked away from the internship, had a fairly dull job for that summer, but was later glad I did. While I missed out on a potentially cool internship, I didn't have to worry about legal considerations when I was job hunting during a recession.
Loaning money to yourself is not an investment. It's Enron-style accounting; a sleight-of-hand to disguise the fact that Congress spent the money intended for our senior citizens' retirements.
The government takes money from the Social Security trust fund, spends it, and gives itself (SS) an IOU. Sure, the IOU is a Treasury bond that promises interest. But since the government is the party that *pays* the interest, as well as receiving it, there's no actual gain. And it's even worse - it's not even a zero-growth savings, because they spent the money. So all those IOUs in the SS fund are really just a big pile of government debt. When the real money in the trust fund starts to run out in few decades, look out. The government will be forced to either raise taxes or cut benefits drastically.
On the other hand, if the politicians take their heads out of the sand and start to do something about it now, maybe we'll have a chance at saving Social Security.
The major problem is that Congress has shown itself incapable of discipline (or integrity!) by its continual raids on the trust fund. I have no reason to believe future politicians will be any more responsible. Personal accounts seem to be the only way to force politicians to get money for non-SS things the old-fashioned way - through taxes with associated political consequences, rather than through on-the-sly theft from the trust fund. And preventing theft from the trust fund is the only way we'll ensure Social Security is there for us when we retire.
Opponents of accounts have legitimate concerns about whether individuals would invest wisely, what to do if they don't, etc. Maybe the answer is limitations to "safe" investments, maybe it's having all SS accounts managed professionally, I don't know. But we should be debating exactly those questions, and how to fix them, not pretending (as the article does) that the current system is in any way either an investment or sustainable.
I think the key sentence in your reply was:
"any real-time Sys Admin knows that the best solution is to give users what rights they need to work."
That's exactly my point - being able to try and use new tools on your own is a fundamental aspect of the "rights they need to work". Particularly in the field of software development, where the available tools are continuously changing and improving.
Dont make them Gods in an environment so they can have Webshots or that rare unecessary upgrade.
I'm not arguing developers should be made Gods on their machine. As a developer, I don't care about or want privileges to upgrade the OS, install new hardware, change firewall settings, or any of a million other sysadmin tasks that need "God" privileges to perform. I'm asking for the ability to install and use the application software of my choice so I can be as productive as possible at my job. In a reasonable environment, that should not require "God" privileges.
I would also argue that useful upgrades are neither unnecessary nor always rare, and that in any case, the developer is the person who is in the best position to determine what is "necessary" to his or her job.
Finally, with regard to the Self Proclaimed Guru screwing up their PC or network: can it happen? Sure. It's a risk that needs to be managed. But risk avoidance isn't the same as risk management. One way to manage that risk in a software development shop: give the developers a mandatory training session on Dos & Don'ts for installing software, and monitor their machines. If they ignored the training and screwed stuff up, you have a policy in which they get educated on their mistake, and in which repeated violations lead to a revokation of privileges.
A closer analogy would be that the machinist has a better wrench out in his truck but isn't allowed to just bring it in the building and use it. First he must put in a call-ticket, then hope that the helpdesk is willing to send somebody out to his truck, carry the new wrench inside, and put it in his working area. Because "it's not the machinist's job" to do that stuff.
The point is that centralizing common and simple tasks wastes everyone's time - the support guy and machinist alike.
Helpdesk is probably understaffed, and almost certainly has (at least from their perspective) more important things to do. Meanwhile, the machinist is stuck with an inferior tool until he can work the bureaucracy to get the new wrench in.
The company loses too because it's using inferior tools, simply because the guys who use them aren't empowered to change their work environment.
And not only is it extraordinarily difficult to bring in new but known-to-be-better tools (sometimes even free ones!), but forget trying to experiment with a tool to find out if it's better. Try convincing an overworked support guy that you really need this application installed because you want to try it out. You'll see snowballs in hell before that tool gets installed. Not through any fault of the support guy - he's just being rational and allocating his limited time to higher priorities. But the system is clearly flawed.
In contrast, if the developer could admin his own machine, he could install something, try it out, and if it's helpful other developers could start using it too.
Now is it possible that the developer could accidentally install malware if he has admin? Sure. But that's why Microsoft monitors their network - they can catch and correct mistakes that happen. They no longer handicap the developers, and IT doesn't have to babysit on simple things like application installs. The company reaps the productivity awards accordingly.
Car manufacturers and other corporations learned years ago that giving the person closest to the problem the power to solve it lets them avoid bottlenecks and reap massive productivity gains. Somehow, the conventional wisdom on IT management hasn't quite caught up yet with the rest of the management world.
If we assume for the sake of argument that:
1. The election will be a close contest between the two "major" parties, with Nader a distant third (almost guaranteed)
2. Nader supporters will vote for Nader unless one of the major candidates comes close enough to the Nader position (plausible)
3. The goal of the Nader campaign is primarily about achieving Nader-like policy (possible), rather than winning the election (which would be nearly impossible)
Then it might make good sense for Nader to run, and Nader voters for to vote for him unless a major candidate adopts a more Nader-like position. Even if he doesn't have a chance of winning.
If the Democrats know they need Nader voters in order to win the election, they could be forced to align their policy more closely with his in order to siphon away a (small but potentially decisive) number of votes. Of course, this makes the (big) assumption that moving closer to the Nader position wouldn't alienate more moderate voters, thus negating the benefit.
This is basically a higher-risk but higher-reward strategy for the Nader constituency. On the one hand, if the Democrats don't adjust leftward, then there's the risk that Nader votes helped elect the Republican. But if the Nader folks vote Democrat without demanding anything for it, the Democrats can take their votes for granted. This would mean a less liberal Democrat position, because the logical thing for Democrats to do in that situation is to swing less liberal in order to pick up more swing votes.
IRV has its share of problems, though. According to
this Approval Voting site,
IRV only helps avoid the spoiler effect when there are exactly two viable candidates. Once a third
candidate becomes viable too, you're back to the
same old problem.
PayPal is a payment middleman, not a bank
True. In essence Paypal is a money delivery service - you give them money, they deliver it to someone you specify.
As a result, it seems to me that Paypal has a moral (and maybe legal, IANAL) obligation to safeguard that money while it's in Paypal's possession. And they should be responsible for ensuring that the person they deliver the money to is indeed the person you specified should receive it.
OTOH, Paypal should not be responsible for anything more than this. If you decide to send someone money, and it turns out you were scammed, well that's not Paypal's fault.
In the AbiWord case, it sure looks like it was a case of the money being outright stolen from the Paypal account. Paypal should refund the money to AbiWord (which really ought to be covered by insurance, anyway. Insurance is a basic part of running any business). And they should certainly assist the victim in launching a criminal investigation for wire fraud.
I don't think it's fair to place the blame entirely on "lazy developers".
As I see it, there are two possibilities when a bank site doesn't work with non-IE browsers:
1. The bank wanted a solution that would work with all browsers, but the developer cut corners and didn't provide it.
2. The bank didn't care.
For #2, I think it's safe to say the blame lies solely with the bank.
For #1, it seems the blame is largely with the developers. After all, the site's ability to work with all browsers was either explicitly stated, or it was implied. There's no reason an ordinary person would think "I want you to build my website" would be interpreted as "I want you to build a website that only some of my customers can use". Unless the developer explicitly states that their proposal is limited to IE, the expectation is (rightfully) that there is no such limitation.
At the same time, though, any organization contracting out such a significant job has a responsibility to exercise some due diligence. Especially a financial organization, due to the need for security. They ought to do enough research (either themselves, or hire a consultant) to know how to discriminate between competing bids. And they ought to ensure before accepting a bid that the developer truly understands their requirements, and that all requirements are in the contract. If they do all that, and the developer doesn't provide everything they said they would, that's breach of contract. If the bank doesn't do its due diligence, then it has to accept a share of the blame for having a half-assed website.
FWIW, Bank of America's site seems to work fine with Mozilla.
The case in question is not frivalous. MS is correct. The mod chips are illegal under current law. They are circumvention devices. They contain copyrighted code. The names probably even infringe on trademark.
That's far from certain or correct:
A) Whether the mod chips are "circumvention devices" is certainly matter a debate. Witness a recent Sony case in Australia (whose law is similar to the U.S.'s DMCA), which found the chips not to be a "circumvention device" under the law. And thus, not illegal.
B) There's a very good chance the chips do not contain any code that is copyrighted by MS. They don't need to. They might reverse-engineer some technical information, and use that to create their own code, but that is not the same as copying MS code, and does not infringe on any MS copyrights.
C) The names may infringe on trademarks, but that does not make the product itself illegal. It just makes selling it under that name illegal - the company could still sell the product under a non-trademark-infringing name.
Yes. That's how courts work. You sue or are sued. A judge decides.
The alternative is no courts, just executive authority to arrest/imprision/confiscate. That has a history of working really well. You think corporations are too powerful now?
Judges toss lawsuits everyday of the week. Its a routine part of the legal system.
I think you're missing the larger, implicit point of the previous poster's comment. It's not that we shouldn't have a judicial system, it's that the current system has a significant bias towards those with wealth. I.e. someone with wealth can afford to file a suit they know is without merit, because it will cost the target of the suit legal fees. If the target doesn't have the money for a lawyer, the wealthy (corporation or individual) essentially wins by default because the target has to stop doing what they're doing, regardless of if it's actually legal. Sure, the suit will eventually get tossed, but in the meantime those bills sure add up fast. Many people can't afford that.
The solution isn't to scrap the legal/judicial system, it's to improve it. How to do that is an interesting and complex question. It's not clear how to easily discourage this sort of legal skirmishing without discouraging legitimate claims as well.
Taking away essential freedoms does not guarantee security. In fact, reduced freedom can often reduce security. If we had a police state, sure we would have a somewhat easier time nailing terrorists. But how secure would you really be? You've just traded the occasional terrorist for an ever-present government tyrant.
It is our freedoms that *provide* our security. Restrictions on governmental/police powers promote the fairness and honesty that enable all citizens to be safe. This is why we require warrants before allowing the government to spy on you or search your property. This is why the police have to have probable cause to arrest you, rather than because "he looked like he was up to no good". If we give up these kind of freedoms in an attempt to fight terrorists, we'll only be less secure. And the terrorists will have won.
It's interesting to note that of all the countries in the world, Americans are probably the safest. And we're the most free. Coincidence? I don't think so.
I'm all for giving the government new tools to help in the fight against terrorism. Reform wiretap laws to have wiretaps be on a per-person, not per-phone basis. Expand the ability to wiretap in cyberspace to match the equivalent in phonetap law. These will help fight terrorism without destroying our freedoms.
Other proposals do the opposite. They remove freedoms without helping the terrorist fight. Mandated encryption backdoors or bans on encryption are a good example of this. While they would appear to help, they really wouldn't. Terrorists would just get their crypto from abroad, while ordinary citizens are now more susceptible to the snooping of cr/hackers and the government.
What is really needed is a cool-headed assessment of what we can do to promote security without jeopardizing our freedom and our way of life. Decreasing our freedoms will only decrease our security in the long term. Let's make ourselves more secure, not less.
I think crypto-guy Bruce Schneier put it well when he said:
"The ideals we uphold during a crisis define who we are. Freedom and liberty have a price, and that price is constant vigilance so it not be taken from us in the name of security. Ben Franklin said something that was often repeated during the American Revolutionary War: 'They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.' It is no less true today."
Yes, I've had both types of managers, but what you are largely talking about is people skills.
:-)
Exactly. People skills. Hence, skilled labor.
But most of this stuff you should have learned in kindergarten.
Partially true. Certain basics you should've learned in kindergarten, but I'm continually amazed at how many adults haven't mastered basic manners. Plus, there's a lot more than kindergarten skills that go into good managers. Motivating people, communicating complex concepts in ways that people can understand, etc.
once a manager has mastered the soft issues, he's pretty much done
But that's the thing - he really isn't done. Like any other skills, effective people skills require that you keep using those skills to keep them in shape. It's kinda like programming - once you've mastered the basic concepts of programming, you could say that you're "pretty much done". But the specific skills - say language X - you need to keep current on or you're not going to be effective. Similarly, managers must keep current on (and the best continually *improve* on) their skills - being able to motivate their team, communicate effectively between their workers and higher management (and maybe customers), and keep the group working smoothly. These may very well be "soft" skills, but they are skills in every sense of the word.
You are right that the "Cope Morphing" does consume some CPU cycles when it's first performed, though it is cached so the performance hit isn't excessive.
One major benefit however is that you drastically reduce the amount of silicon you need to build your chip. In some of the modern CPUs like the PIII, instruction decoding (the very thing Transmeta is doing in their Code Morphing) can take up half your silicon. That's a lot of savings in power, heat dissipation, and cost.
Transmeta took this in one logical direction and created a mobile CPU. This makes sense, and is a good way to get into a market where the competition from Intel/AMD wasn't as formidable. But here's another application: instead of just throwing out that 50% of silicon real estate, put in more integer and floating point units, maybe increase the cache. That 50% will buy you a lot of extra processing power.
Suddenly, they'll have a powerhouse chip that may very well outperform Intel and AMD's offerings at a comparable power/heat/cost. The hardware changes would be relatively simple, and would require modest changes to the Code Morphing software to make use of the extra hardware units. Transmeta could do this without much difficulty.
Will they? Not until they get themselves more firmly established in the mobile market. But once they have the financial muscle to take on Intel/AMD on their home turf, I think they will. The profit margins on desktop/server chips too high to pass up.
Let me share what I've seen at my school with ECE vs. CS majors, and their experiences with hardware/architecture.
I expect that which major - ECE vs CS - you choose will depend largely upon how the individual school structures their programs. At Carnegie Mellon, where I am currently a senior, those interested in hardware and architecture design would do best to major in ECE, as that is where much more emphasis/coursework is to be had in those areas.
Keep in mind that if you try hard enough, you can probably get away with being a CS major and taking the hardware courses through the ECE Dept, it's just harder due to prerequisites. Similarly, you can be an ECE major and take the stereotypically CS courses. Which says something about the flexibility about both programs here (both programs are among the best in the nation) but I don't know how flexible other schools may be with that. YMMV.
The reason, it seems to me, that there is debate about which is better for a given interest is because there is significant overlap between the two fields. People in both areas have to know the basics of hardware and software, just because each has to interact with the other. Which aspect you want to specialize in will probably determine your choice of major. I chose to major in ECE because I didn't know which path I wanted to take; it's looking now more like software, so I'm taking a bunch of CS classes, but I find my hardware background to be very valuable in my software work as well. I don't think I'd have been as well prepared if I had started in CS and tried to migrate towards hardware.
So my advice to someone choosing a major:
1. Check how your school of choice structures their program. Maybe even try to contact faculty at the school, and ask them questions. This more than anything will help you figure out which would best match your interests.
2. If that doesn't give enough info to make your choice, go into CE. It will give you a broad foundation from which you can easily migrate to CS if you later find that's what you want.
>Dave Powell is just using that system.
The system being flawed is not a justification for the abuse of that flaw by individuals/entities (such as, in this case, David Powell/CCS). Just because the system allows something doesn't mean it's right.
If a website has poor security, does this make it okay to rip off credit card numbers from the site?
His abuse of the legal system to force huge legal bills on people who haven't been convicted of a single thing to me seems to be a simple case of the richer party bullying the poorer one. It's to the point where acual guilt or innocence isn't really the issue, it's "how much money can we get out of this guy?".
And that's sad.
I'm also from NY, and knowing people who have gone through the NY court system about a non-compete agreement, one warning to those who are thinking along the lines of "it isn't enforceable" etc.
Whether or not it is enforceable is NOT necessarily your biggest problem. If you sign such an agreement, later leave that company, and they claim a violation of the non-compete (even if you didn't ACTUALLY violate anything), THE BURDEN IS ON YOU to prove that the contract is not enforceable. This means that you have the great expense of hiring a lawyer to prove this in court, even if you win. Also consider that these suits can be dragged out by your former employer for many years. While the suit is unresolved, keep in mind that the suit may have consequences on who may be willing to hire you. Or if you started your own firm, it may scare off potential investors. All of this, even if the company suing you is utterly wrong.
As far as the legality of the non-competes go, from my understanding (IANAL) they are legal as long as they fall within certain constraints specified by the law. For example, they must have a limited geographic area - a company can't make you sign a noncompete that covers the whole world. Maybe they could say you can't work for a competitor west of the Mississippi (arbitrary, yes, and in some ways illogical considering the global economy, but such is the law). The contract cannot preclude you from being able to make a living (ie if you're a programmer it can't preclude you from working for any other software firm, though they may be able to specify certain subsets of software firms as off-limits).
If you are presented with a non-compete as a condition of employment, try to see if you can get them to hire you without it. If you know other employees of the company, find out if they had to sign. If they did not, this should help your case.
Also note that non-disclosure is a different beast than non-compete. Non-disclosure is much more acceptable, you aren't precluded from working for a competitor, you just can't share any proprietary information with your new employer. While this can be a tricky area (some companies seem to think that anything is their proprietary info, even if it's something that clearly is not - such as your general C++ or Perl skills - that sort of arrogance tends to appear particularly in those cases where the employer provided training)
My biggest advice - TALK TO A LAWYER BEFORE SIGNING ANY EMPLOYMENT AGREEMENT. It may save you a lot of stress down the road. Also try to get a lawyer who is familiar with the employment practices of the industry you're in - they can give you information about how common things like requiring non-competes are in your specific industry.
And again, talk to a lawyer. You don't want your career to get fouled up over a lawsuit you could have prevented with some prior diligence.
yeah, I had the 1541 so didn't have to use the cassette drive much. Oh, the days of running games off floppies :-)
As noted by several others in this thread...
the above post is way, way off topic - talking about browser standards in a thread about backing up to DV tapes. how did it ever get modded to +4?!
using the tape recorder with the good ol' Commodore-64 :-)
New Scientist had an article on spintronics a while back (Feb 1998). Does a good job of explaining things.
>Do you understand the need for a manual recount now?
The problem is that with every additional recount you do (manually OR by machine), you introduce further error into the count. This is because with a punchcard system such as they're using in Florida, moving the punchcards around may break off chads - which may or may not have been actually punched through by the voter (they may have only been indented, or "dimpled"). It may have been that they were about to vote for the candidate, dimpling the chad, and then didn't vote for anyone. Now during the recount, the chad falls out and it's counted as a vote the voter didn't intend. Or they may have been about to vote for a candidate, and then voted for another - in which case if in the next recount the dimpled/pregnant/whatever chad for the almost-voted-for candidiate falls off, as commonly happens with these punchcards, then that vote will be invalidated because it now looks like they voted for two presidential candidates.
And there's no way for us to know which of these situations may or may not have occurred with each ballot.
This is why there were different results in each of the recounts by machine, because sending them through the machine causes more chads to fall off (sending them through the hands of human counters would have much the same effect, as they get flexed and moved around, etc). Which is also why a manual recount isn't going to improve your accuracy, because the process of recounting itself is changing what the ballots are showing. Even if you ignore the potential for bias among human counters, the ballots they're trying to count are no longer going to show the same thing as they did on election night due to the physical limitations of the cards.
I personally would like to see more counties moving towards electronic systems such as the touchscreen-based ones used in several counties nationally. They look much like an ATM, and people have found them very easy to use. This eliminates this ridiculous situation of having to look at chads, and somehow try to divine the intent of the voter from how much a chad is hanging off, or how much it's dimpled, etc.
More numbers:
The top 1% of the US population pays 35% of the federal income tax. The top 5% pays 54% of the federal income tax. (Source: Wall Street Journal, dead tree version from about a week ago, or I'd give a link)
A large chunk of the population (I don't remember exact percentage, I think about one-third) doesn't pay ANY federal income tax. So of course, a tax cut isn't going to help those people - but that's perfectly fine, since they're paying NOTHING as it is. Further, I see no problem with a larger dollar amount of refund going to those who paid more taxes - we have a surplus, which means everyone overpaid, which means those who overpaid more should get more back (in proportion to how much they overpaid). Seems only fair.