Again, I agree totally that, most of the time and for most cases, living under the GC is a Good Thing. I disagree with your 99%/1% comparison, though, because that depends entirely on what you're writing and for what kind of system. I'm talking in generalities. I'm not talking about just in.NET.
I tend to view things from what kind of development work that I do, and that does not include web app development -- from the perspective you're looking at things from, thrashing the gc is probably a more frequent problem.;)
The Finalize method might not run to completion or might not run at all in the following exceptional circumstances: * Another finalizer blocks indefinitely (goes into an infinite loop, tries to obtain a lock it can never obtain and so on). Because the runtime attempts to run finalizers to completion, other finalizers might not be called if a finalizer blocks indefinitely. * The process terminates without giving the runtime a chance to clean up. In this case, the runtime's first notification of process termination is a DLL_PROCESS_DETACH notification.
All WIN32_LEAN_AND_MEAN does is exclude some headers from being included. All it does is make your code compile faster. It has nothing to do with execution speed or what libraries you link to.
...and of course, since MS came up with it, the blind assumption is that the.NET framework and CLS languages are a step backwards.
Which is incorrect.
COM *is* dying. It won't be dead for a very, very long time. In much the same way that OLE (what COM replaced) still isn't dead, and won't be for a very long time. And just as doing things the COM way was better than doing them the OLE way, doing things in.NET is generally better than doing them in COM.
COM is just a way to create and use objects between processes..NET code doesn't communicate between.NET processes using a COM wrapper. However, it does communicate with COM classes using a proxy class which implements a COM wrapper. COM doesn't do anything other than that. All the extra stuff you get with.NET isn't present in COM.
The rest of the stuff in.NET is analogous to MFC and the C++ stdlib. MFC is also just a wrapper on top of Win32 functions, so nothing lost there -- and I'm sure most people would agree that MFC just needs to die a painful death. And of course, the stdlib is just a bunch of standard functions that end up calling the Win32 API at some point anyway. The CLR implements these things, and the neat thing about it is that the CLR is common between all.NET languages.
Most of the developers will be going to.NET not because it's "what they're told", but because it's better. If you don't agree, that's fine, but don't be fooling yourself into thinking that the only reason it's being adopted is because you think it's being crammed down people's throats.
Modern doesn't mean you're not in a "corner case", though. Memory-intensive software in a large memory space is a "corner case", and an increasing number of "modern" applications are appearing on embedded systems with extremely limited memory.
Embedded systems aren't an issue, at least for now. It isn't practicle to write.NET code for a system that can't execute it.:) I should have been more clear and said "modern windows pc" and not "modern computer."
What I'm basically getting at is that most people seem to hate garbage collection because they lose control over stuff. The thing is, that loss of control doesn't matter 99% of the time. And for that 1% of the time it matters, you can still do it the old way. And the net result is that it makes life as a programmer much easier and leads to more stable applications.
2) Finalize is guaranteed to be called before the memory is released. There is no guarantee that the memory will ever be released (ex: circular reference). So there is no guarantee that the finalize method will ever be called.
I don't know enough about.NET to comment, but if there's an interface you can implement to provide uniformity in the call and use of that method, that's great. Java, AFAIK, has no such interface, so hand-made deterministic cleanup is idiosyncratic. That's okay, but it's not ideal. What's more, though, let me ask you this- in some large middleware or object framework following your idea, what guarantee is there that your disposal method won't accidentally get called twice? This could lead to indeterminate states in the system that aren't immediately understood, since there's no check against that implicit. At least with a C++ destructor, destroying the object guarantees that further use of the object is impossible. No such guarantee is available with homespun management. Yes, the roll-your-own you're describing is good enough, but that doesn't mean it's without flaw.
Have your object implement the IDisposable interface to spec and override the finalize method. Call.Dispose when you want to get rid of your resources. Calling.Dispose multiple times should be harmless.
Maybe, but again, think about situations where you're trying to minimize memory use. Deterministic destruction makes memory immediately available again. You can put a new object in that freshly freed memory. With a GC, that may not be possible. Thus, I dispose() my object, which scrubs it clean, then I throw it to the wolves...only they're not hungry just yet. I go to make a new object, and that memory isn't [...]
Having a garbage collector means you don't have to care about memory management and optimization. In fact, odds are that the memory management code can do a better job of optimizing memory usage than your own code can. It can compress the memory store when things get tight (something very difficult to do with unmanaged code), but when things arn't tight it doesn't have to waste time constantly allocating/releasing tiny blocks of memory.
On top of that, if you *really* don't like the gargabe collector you get by default, you can roll your own and create an instance of the managed runtime that uses YOUR garbage collector.
If you're in the corner case where you've got a small of memory to work with and you're trashing the GC, then yeah, writing an app in managed code is NOT a great idea. On a modern computer it isn't an issue.
The.NET bytecode was designed to make it easy to JIT. Java was not. It's hard to make a JIT to make Java code run fast. It isn't nearly as hard to make a JIT to run.NET code fast.
They arn't backing off from calling everything.NET because they overused it, or because the term became meaningless. It's changing for a few reasons, mainly because nobody at Microsoft has really figure out a good way to communicate what.NET really is. Even the team that developed it can't summarize what it is with a short statement..NET is being dropped from Office/Windows names because it didn't make sense to have it there (well, it made about as much sense as calling Win2k Server "Win2k COM+ Server")..NET languages don't introduce any new revolutionary concepts to the OOP world. They added a few nifty things that I haven't seen in other languages (attributes), and improved on several things that were "painful" to do in C++ (delegates), but it's nothing new. Writing a class in C# isn't significantly different than doing so in C++.
Performance wise, C# is very close in performance to C++ code. In some cases it may be faster, in some cases it may be slower. The JIT compiling/optimization is very impressive.
Most of the resistance I've seen in moving to it is that it's an unknown. Which is reasonable -- you don't want to start a big project when the system you're basing it on is a giant question mark. But don't let the thing remain a giant question mark. It's a very neat set of technology.
Well, you CAN use COM in new programs you create in.NET, but you're generally making your life much harder than it has to be when you do and it doesn't really do you any good. Only reason why you'd want to is because your.NET code needs to implement a COM interface that older code interacts with...
I didn't say it was following unix, or unix standars, but that it's goal is to be "like" unix. Linux IS a unix *variant*. To say that it isn't is silly. If I sit down at the machine, I get a unix shell. I run ps and get a list of process running on the system. I run cat and get the contents of a file flashing by on the screen. If I run X I get a funky gui system.
Whereas Windows is most definately NOT a VMS system. VMS may have been written by the guy who did the core of NT, but it sure wasn't the design goal of the system.
Whoever is charging $500 for Office is ripping you off (*cough* retail stores *cough*). The OEM enterprise edition costs $300 from newegg.com -- that's about $50 an app + a bunch of utils thrown in. If you want to get a package for grandma, get the OEM MS Works suite, which costs $75.
The cost of software and hardware are not linked. It doesn't make any sense to link them, no more so than linking the cost of gas with the cost of your car.
I find it strange that everyone here thinks that "innovation" == "new application that nobody has thought about before." If that's the way you think, then the guy who thought the patent office should be closed because he thought everything has already been invented was right. An improvement to an existing idea is an "innovation." "Revolutionary" would be "a new application that nobody has thought about before."
Yeah, that GUI was invented in the 80's. Are you saying that Win2k is no better than Xerox's GEM? MacOS 6? Win3.1? NT4?
What about spreadsheets -- you saying that Excel is not capable of doing anything more than 1-2-3, or that Word only has features that WP has?
Shoot, if you want to go by the criteria, the computing industry has been stagnant since the mid 80's.
Oh please, home versions of WinXP + Office do not cost $500. OEM versions will cost you half that, if you yourself ordered the software. Do you honestly think that HP pays retail prices for software?
When was the last time you parted together a $300 system with a printer and a monitor? I'd like to see a spec list and prices for that system, because I could sure use a few of them. Hell, an xbox costs more than $300 to make...
Look in the weekend paper. You'll see adds for computers the same price points they were 2 years ago. Instead of 500mhz cpu's and 128mb of ram, they've got ghz cpus and half a gig of ram. The amount of money people are willing to spend on a computer hasn't changed. What you get for that money has.
No, only two cars were parked in the street. One old truck (an '84 ranger), one old car (a purple '88 lincon of some sort), one or two in the driveway (roommates gf car and other random car of a friend or something), and two in the garage (new cars).
As I said, considering that each house on the street had at least 1 car parked in front of it (some 2, some 3, some 4, and most without any in the driveway) I don't think it was unreasonable to have 2 parked in front of ours.
Tell me about it... I used to live in a house with a friend of mine. When I bought my new car I didn't get rid of my old truck; decided it'd make a good beater for my daily trip to work (to an area of town where a nice shiny new car would probably be vandalized). My roommate did the same thing a few months later. And his girlfriend started staying the night.
So, in a house with a two car garage and driveway, there were 5-6 vehicles that needed to be parked around it, two of which were normally parked in the street.
You would not believe the number of letters from the subdivision administration group claiming that the cars were abandoned and that we needed to get rid of them. Or the cops that would show up and ask us to prove that the vehicles would move under their own power.
I swear if I ever meet the person who kept bitching about it I'd give 'em a taste of their own medicine. Especially considering the number of vehicles parked down that street (every house had at least one car parked in front of it...).
Well, the real question is, if 95% of your target audience uses hardware better than your target of a 500mhz PIII, is it really worth spending a lot of extra time to make it work well (not just work, but work well) on a P90?
The perceptive performance "bar" remains the same. The bar is "it's usable on what the customer is using". What you have to do to meet that bar is what changes.
Believe it or not, this already happens. There are performance goals that certain features must meet, or it's considered a defect.
If you don't believe that, sit down for a minute and think about all of the crap that must be going on in the background after/while you type a sentence... spell checker, grammar, macro checks, formatting, replacing a commonly misspelling with the correct spelling, etc.
...or for that matter, the fact that he isn't considered imprisoned, merely detained. Or any evidence you would use in your arguement in any court is sealed.
Exactly my point. Without the patriot act it took 8 years to commit a subsequent terrorist act on US soil. So how after less than a few years can anyone conclude that the Patriot Act is doing anything?
I call a person who doesn't research what they're getting into an idiot. Especially when you sign your name on a legal document of any kind.
Contractors pay takes into account benefits (and taxes and all other sorts of crap). Ie: the pay includes the money to buy your own health insurance. Which means they must pay for their own benefits. Which is why they get paid more. And this is also why you consider that information when considering a contract. If you think you can do better elsewhere, work elsewhere.
The people you're referring to were fired. After which they were offered a contracting position after termination. They read the contract, knew what they were getting into, and agreed to the terms. If you don't like it, move on. You might argue that's a nasty thing to do; great. I'm happy for you. But that's not what's being talked about here. What's being talked about is how contract employees are treated now, post lawsuit.
The enviornment at MS is pretty cool. They try to keep all of their workers happy. Stupid stuff like free soda, renting out movie theaters for a day, and so on. And hey, happy people are productive people. So they wanted their contractors to be happy to, so bam, before the lawsuit they weren't kept from participating in all of this stuff.
And then they sued, argueing that they were really full time employees, entitled to their contract pay (which when you negotiate a contract should include money for benefits) + benefits. And one of their arguements for saying that they were really full time employees was that they got to partake in the stupid stuff MS does to keep employees happy.
So what does MS do? They change the rules so that contractors can no longer participate in the morale stuff. WTF did you expect them to do?
What would I do if I was given the option of taking a contract job? I'd look it it, compare it to what I was making now after taking into account benefit, tax expenses, & the time it takes me to take care of it. And if it was a crappy salary, I'd turn it down. And if that meant I didn't have a job tomorrow, so be it. I did exactly that on January 17th. Started a new Job on Feb 3rd at a rate almost 50% more than I was making before. Take a wild guess where I started.;)
No, I believe that they'll continue to do what they've always done. Al Queda didn't just pop into existance. They've been around for a lone time, committing many terrorists acts abroad.
The law enforcement branches in this country have all of the power they need to get their job done. It's been shown that law enforcement agencies had all of the informationed needed to stop the events of 9/11, except it didn't get the attention it needed (ie: a process problem, not a "laws keep us from doing what needs to be done" problem).
Why is this done? Because a bunch of contractors sued Microsoft wanting to get contractor pay but employee benefits, argueing that they were really employees because they worked for MS for longer than a certain length of time.
So now contractors can only work for MS a time shorter than that length of time. Then they've got to work for someone else for awhile.
So what if contractors don't get all of the nice benefits that employees have. They get paid a lot more than normal employees to make up for it. Anyone who doesn't take into account that they've got to pay their own benefits when considering a contract position is an idiot.
Slashdot Mirror
Again, I agree totally that, most of the time and for most cases, living under the GC is a Good Thing. I disagree with your 99%/1% comparison, though, because that depends entirely on what you're writing and for what kind of system. I'm talking in generalities. I'm not talking about just in .NET.
;)
I tend to view things from what kind of development work that I do, and that does not include web app development -- from the perspective you're looking at things from, thrashing the gc is probably a more frequent problem.
Unfortunately, nothing is perfect.
You're right to some extent, but so am I. :P
r l= /library/en-us/cpref/html/frlrfsystemobjectclassfi nalizetopic.asp
The Finalize method might not run to completion or might not run at all in the following exceptional circumstances:
* Another finalizer blocks indefinitely (goes into an infinite loop, tries to obtain a lock it can never obtain and so on). Because the runtime attempts to run finalizers to completion, other finalizers might not be called if a finalizer blocks indefinitely.
* The process terminates without giving the runtime a chance to clean up. In this case, the runtime's first notification of process termination is a DLL_PROCESS_DETACH notification.
http://msdn.microsoft.com/library/default.asp?u
But I do agree that it's reasonable to expect that the finalize method always be called at some point during the life of an object.
All WIN32_LEAN_AND_MEAN does is exclude some headers from being included. All it does is make your code compile faster. It has nothing to do with execution speed or what libraries you link to.
...and of course, since MS came up with it, the blind assumption is that the .NET framework and CLS languages are a step backwards.
.NET is generally better than doing them in COM.
.NET code doesn't communicate between .NET processes using a COM wrapper. However, it does communicate with COM classes using a proxy class which implements a COM wrapper. COM doesn't do anything other than that. All the extra stuff you get with .NET isn't present in COM.
.NET is analogous to MFC and the C++ stdlib. MFC is also just a wrapper on top of Win32 functions, so nothing lost there -- and I'm sure most people would agree that MFC just needs to die a painful death. And of course, the stdlib is just a bunch of standard functions that end up calling the Win32 API at some point anyway. The CLR implements these things, and the neat thing about it is that the CLR is common between all .NET languages.
.NET not because it's "what they're told", but because it's better. If you don't agree, that's fine, but don't be fooling yourself into thinking that the only reason it's being adopted is because you think it's being crammed down people's throats.
Which is incorrect.
COM *is* dying. It won't be dead for a very, very long time. In much the same way that OLE (what COM replaced) still isn't dead, and won't be for a very long time. And just as doing things the COM way was better than doing them the OLE way, doing things in
COM is just a way to create and use objects between processes.
The rest of the stuff in
Most of the developers will be going to
Modern doesn't mean you're not in a "corner case", though. Memory-intensive software in a large memory space is a "corner case", and an increasing number of "modern" applications are appearing on embedded systems with extremely limited memory.
.NET code for a system that can't execute it. :) I should have been more clear and said "modern windows pc" and not "modern computer."
:)
Embedded systems aren't an issue, at least for now. It isn't practicle to write
What I'm basically getting at is that most people seem to hate garbage collection because they lose control over stuff. The thing is, that loss of control doesn't matter 99% of the time. And for that 1% of the time it matters, you can still do it the old way. And the net result is that it makes life as a programmer much easier and leads to more stable applications.
Anyway, that's my 2c plus some change.
2) Finalize is guaranteed to be called before the memory is released. There is no guarantee that the memory will ever be released (ex: circular reference). So there is no guarantee that the finalize method will ever be called.
I don't know enough about .NET to comment, but if there's an interface you can implement to provide uniformity in the call and use of that method, that's great. Java, AFAIK, has no such interface, so hand-made deterministic cleanup is idiosyncratic. That's okay, but it's not ideal. What's more, though, let me ask you this- in some large middleware or object framework following your idea, what guarantee is there that your disposal method won't accidentally get called twice? This could lead to indeterminate states in the system that aren't immediately understood, since there's no check against that implicit. At least with a C++ destructor, destroying the object guarantees that further use of the object is impossible. No such guarantee is available with homespun management. Yes, the roll-your-own you're describing is good enough, but that doesn't mean it's without flaw.
.Dispose when you want to get rid of your resources. Calling .Dispose multiple times should be harmless.
Have your object implement the IDisposable interface to spec and override the finalize method. Call
Maybe, but again, think about situations where you're trying to minimize memory use. Deterministic destruction makes memory immediately available again. You can put a new object in that freshly freed memory. With a GC, that may not be possible. Thus, I dispose() my object, which scrubs it clean, then I throw it to the wolves...only they're not hungry just yet. I go to make a new object, and that memory isn't [...]
Having a garbage collector means you don't have to care about memory management and optimization. In fact, odds are that the memory management code can do a better job of optimizing memory usage than your own code can. It can compress the memory store when things get tight (something very difficult to do with unmanaged code), but when things arn't tight it doesn't have to waste time constantly allocating/releasing tiny blocks of memory.
On top of that, if you *really* don't like the gargabe collector you get by default, you can roll your own and create an instance of the managed runtime that uses YOUR garbage collector.
If you're in the corner case where you've got a small of memory to work with and you're trashing the GC, then yeah, writing an app in managed code is NOT a great idea. On a modern computer it isn't an issue.
The .NET bytecode was designed to make it easy to JIT. Java was not. It's hard to make a JIT to make Java code run fast. It isn't nearly as hard to make a JIT to run .NET code fast.
They arn't backing off from calling everything .NET because they overused it, or because the term became meaningless. It's changing for a few reasons, mainly because nobody at Microsoft has really figure out a good way to communicate what .NET really is. Even the team that developed it can't summarize what it is with a short statement. .NET is being dropped from Office/Windows names because it didn't make sense to have it there (well, it made about as much sense as calling Win2k Server "Win2k COM+ Server"). .NET languages don't introduce any new revolutionary concepts to the OOP world. They added a few nifty things that I haven't seen in other languages (attributes), and improved on several things that were "painful" to do in C++ (delegates), but it's nothing new. Writing a class in C# isn't significantly different than doing so in C++.
Performance wise, C# is very close in performance to C++ code. In some cases it may be faster, in some cases it may be slower. The JIT compiling/optimization is very impressive.
Most of the resistance I've seen in moving to it is that it's an unknown. Which is reasonable -- you don't want to start a big project when the system you're basing it on is a giant question mark. But don't let the thing remain a giant question mark. It's a very neat set of technology.
Well, you CAN use COM in new programs you create in .NET, but you're generally making your life much harder than it has to be when you do and it doesn't really do you any good. Only reason why you'd want to is because your .NET code needs to implement a COM interface that older code interacts with...
I didn't say it was following unix, or unix standars, but that it's goal is to be "like" unix. Linux IS a unix *variant*. To say that it isn't is silly. If I sit down at the machine, I get a unix shell. I run ps and get a list of process running on the system. I run cat and get the contents of a file flashing by on the screen. If I run X I get a funky gui system.
Whereas Windows is most definately NOT a VMS system. VMS may have been written by the guy who did the core of NT, but it sure wasn't the design goal of the system.
Whoever is charging $500 for Office is ripping you off (*cough* retail stores *cough*). The OEM enterprise edition costs $300 from newegg.com -- that's about $50 an app + a bunch of utils thrown in. If you want to get a package for grandma, get the OEM MS Works suite, which costs $75.
The cost of software and hardware are not linked. It doesn't make any sense to link them, no more so than linking the cost of gas with the cost of your car.
I find it strange that everyone here thinks that "innovation" == "new application that nobody has thought about before." If that's the way you think, then the guy who thought the patent office should be closed because he thought everything has already been invented was right. An improvement to an existing idea is an "innovation." "Revolutionary" would be "a new application that nobody has thought about before."
Yeah, that GUI was invented in the 80's. Are you saying that Win2k is no better than Xerox's GEM? MacOS 6? Win3.1? NT4?
What about spreadsheets -- you saying that Excel is not capable of doing anything more than 1-2-3, or that Word only has features that WP has?
Shoot, if you want to go by the criteria, the computing industry has been stagnant since the mid 80's.
But there is one important difference.
Linux strives to be like Unix. When you speak of a Linux, you're thinking about a unix-like operating system.
Windows does not strive to be like VMS. When you talk about windows, you arn't thinking about VMS.
Oh please, home versions of WinXP + Office do not cost $500. OEM versions will cost you half that, if you yourself ordered the software. Do you honestly think that HP pays retail prices for software?
When was the last time you parted together a $300 system with a printer and a monitor? I'd like to see a spec list and prices for that system, because I could sure use a few of them. Hell, an xbox costs more than $300 to make...
Look in the weekend paper. You'll see adds for computers the same price points they were 2 years ago. Instead of 500mhz cpu's and 128mb of ram, they've got ghz cpus and half a gig of ram. The amount of money people are willing to spend on a computer hasn't changed. What you get for that money has.
No, only two cars were parked in the street. One old truck (an '84 ranger), one old car (a purple '88 lincon of some sort), one or two in the driveway (roommates gf car and other random car of a friend or something), and two in the garage (new cars).
As I said, considering that each house on the street had at least 1 car parked in front of it (some 2, some 3, some 4, and most without any in the driveway) I don't think it was unreasonable to have 2 parked in front of ours.
Tell me about it... I used to live in a house with a friend of mine. When I bought my new car I didn't get rid of my old truck; decided it'd make a good beater for my daily trip to work (to an area of town where a nice shiny new car would probably be vandalized). My roommate did the same thing a few months later. And his girlfriend started staying the night.
So, in a house with a two car garage and driveway, there were 5-6 vehicles that needed to be parked around it, two of which were normally parked in the street.
You would not believe the number of letters from the subdivision administration group claiming that the cars were abandoned and that we needed to get rid of them. Or the cops that would show up and ask us to prove that the vehicles would move under their own power.
I swear if I ever meet the person who kept bitching about it I'd give 'em a taste of their own medicine. Especially considering the number of vehicles parked down that street (every house had at least one car parked in front of it...).
Me too! The only thing I'd rather see in a game like that is support for a clutch pedal on the aftermarket steeringwheel/pedal controllers...
Well, the real question is, if 95% of your target audience uses hardware better than your target of a 500mhz PIII, is it really worth spending a lot of extra time to make it work well (not just work, but work well) on a P90?
The perceptive performance "bar" remains the same. The bar is "it's usable on what the customer is using". What you have to do to meet that bar is what changes.
Believe it or not, this already happens. There are performance goals that certain features must meet, or it's considered a defect.
If you don't believe that, sit down for a minute and think about all of the crap that must be going on in the background after/while you type a sentence... spell checker, grammar, macro checks, formatting, replacing a commonly misspelling with the correct spelling, etc.
...or for that matter, the fact that he isn't considered imprisoned, merely detained. Or any evidence you would use in your arguement in any court is sealed.
Exactly my point. Without the patriot act it took 8 years to commit a subsequent terrorist act on US soil. So how after less than a few years can anyone conclude that the Patriot Act is doing anything?
I call a person who doesn't research what they're getting into an idiot. Especially when you sign your name on a legal document of any kind.
;)
Contractors pay takes into account benefits (and taxes and all other sorts of crap). Ie: the pay includes the money to buy your own health insurance. Which means they must pay for their own benefits. Which is why they get paid more. And this is also why you consider that information when considering a contract. If you think you can do better elsewhere, work elsewhere.
The people you're referring to were fired. After which they were offered a contracting position after termination. They read the contract, knew what they were getting into, and agreed to the terms. If you don't like it, move on. You might argue that's a nasty thing to do; great. I'm happy for you. But that's not what's being talked about here. What's being talked about is how contract employees are treated now, post lawsuit.
The enviornment at MS is pretty cool. They try to keep all of their workers happy. Stupid stuff like free soda, renting out movie theaters for a day, and so on. And hey, happy people are productive people. So they wanted their contractors to be happy to, so bam, before the lawsuit they weren't kept from participating in all of this stuff.
And then they sued, argueing that they were really full time employees, entitled to their contract pay (which when you negotiate a contract should include money for benefits) + benefits. And one of their arguements for saying that they were really full time employees was that they got to partake in the stupid stuff MS does to keep employees happy.
So what does MS do? They change the rules so that contractors can no longer participate in the morale stuff. WTF did you expect them to do?
What would I do if I was given the option of taking a contract job? I'd look it it, compare it to what I was making now after taking into account benefit, tax expenses, & the time it takes me to take care of it. And if it was a crappy salary, I'd turn it down. And if that meant I didn't have a job tomorrow, so be it. I did exactly that on January 17th. Started a new Job on Feb 3rd at a rate almost 50% more than I was making before. Take a wild guess where I started.
No, I believe that they'll continue to do what they've always done. Al Queda didn't just pop into existance. They've been around for a lone time, committing many terrorists acts abroad.
The law enforcement branches in this country have all of the power they need to get their job done. It's been shown that law enforcement agencies had all of the informationed needed to stop the events of 9/11, except it didn't get the attention it needed (ie: a process problem, not a "laws keep us from doing what needs to be done" problem).
Why is this done? Because a bunch of contractors sued Microsoft wanting to get contractor pay but employee benefits, argueing that they were really employees because they worked for MS for longer than a certain length of time.
So now contractors can only work for MS a time shorter than that length of time. Then they've got to work for someone else for awhile.
So what if contractors don't get all of the nice benefits that employees have. They get paid a lot more than normal employees to make up for it. Anyone who doesn't take into account that they've got to pay their own benefits when considering a contract position is an idiot.