Federal rail regulations being what they are, the only prospect for high speed rail is if the entire system is grade separated - that is, there are no at-grade crossings.
Experience with high-speed rail in Europe indicates that you really don't want at-grade crossings. They're just massively dangerous, especially with trains going at over 200kph. You also want to put stout fencing around the line to keep out vehicles that aren't supposed to be there in order to prevent accidents.
I often wonder why high-speed rail couldn't be built in the empty median of interstate highways.
The key problem is that most of the places you really want to build high-speed rail (i.e., relatively densely populated regions) you're much less likely to have enough room in the median. Sure there's plenty of room in the midwest, but there's also not the population density to make investing in high-speed rail lines there. (Well, not for now. No point in worrying about things too far off in the future though.)
I'm no more into knocking mass transit than he... was... but I can no more help manipulating numbers than I can help breathing, and the numbers show that mass transit works well where you have heavy population density, which most of the USA does not.
He's very selective with those numbers, you know. In particular, he's not making any allowance for the fact that one railcar can carry a lot more people than one automobile.
But to your main point, you should note that building fast rail in the US is sensible, but building a fast transcontinental service that serves ever settlement along the way is not. If someone's going from NYC to LA, they should fly. It's the short-range inter-conurbation hops that ought to be done more often by high-speed express rail. (Moreover, when you see actual plans of what people want to do, instead of pipe-dreams by people who aren't involved, it's those sorts of situations where action is really proposed. <sarcastic> It's almost like someone involved is an engineer with a clue. Funny that. </sarcastic>)
There's also at least a small chance that many of the kernel hackers who work on Linux today would have been working on the Hurd kernel.
I doubt it would have happened. The Hurd hackers wanted to do fundamental OS research, and everyone else wanted a "Unix" kernel that they could just use and hack around with, and which didn't cost a lot.
I can remember that the biggest factor in our little group of hackers moving to Linux (from 386BSD) was that it had working shared libraries. OK, they sucked in many (many!) ways, but it still meant that you didn't need to have loads of copies of libc in memory or on disk at once. On the small machines of the time, that was a massive saving.
There was an ad masquerading as an article by Michael Krigsman the CEO of Asuret, Inc., a software and consulting company dedicated to reducing software implementation failures.
I've found a workaround. I didn't read the article.
Victory #1: You're using version control! Victory #2: You're using something distributed!
Actually, there's a level of victory between those two: a version control system that can manage addition and removal of directories. That was another key step forward of CVS over RCS. (Really. I remember using RCS and I won't ever go back there.)
For small businesses with a single point of contact, maybe cloud storage is fine. However, for bigger businesses, it is better off to just go with a d2d2t solution, and offsite backups. This way, data is physically protected from compromise, but is stored redundantly.
You're right about small businesses. They typically won't have a dedicated sysadmin at all; the owner, owner's spouse, or (in a slightly larger business) secretary will occasionally look after the computer(s), but they won't be able to carry the overhead of a dedicated tech support staff. For these sorts of firms, any backups are a good step forward and backups to the cloud have the benefit of not being so inclined to be lost in a fire.
As the size of business considered increases, your suggestion of d2d2t2offsite is reasonable (for backup; the Cloud's about much more than just backup of course). However, even that doesn't scale up too well. For big corporations, managing datacenters is a significant problem and for almost all of them, it's not their core business. For them, the cloud is a good choice once again since it lets them expand without having to build (or acquire) and provision new datacenters. It's about outsourcing. It's about flexibility. It's about accountability[*]. It's about the realization that keeping everything in house doesn't necessarily help; they need a data security compliance officer with authority to kick butt and stop crap providers from being used, but they need that sort of position anyway. They might not have it, of course; many businesses are not very well run. No change there...
I wouldn't put my private data up even onto a cloud of a company I trust completely.
And you're going to pay to maintain your own hardware and software installations as an upshot of that choice. As long as you're willing to deal with the consequences, your decision is fine. The only time there's a problem with the cloud is when you're forced into using it for your private data because there's no choice. (But then again, that's generally when there's a monopoly about instead of a free market...)
BTW, successful cloud providers are probably more likely to take good care of your data than some random corporate datacenter. For one thing, the cloud providers have to have competent and security-aware technical staff. All you need to have to own and run a datacenter is a building with enough power, AC and networking, and someone who can plug a rack in.
There's nothing particularly wrong with plain C as a first language. (I'd avoid all the intricacies of C++ syntax for a first-timer. The OO stuff is, in my opinion, totally unnecessary for a first-time programmer to learn.)
Plain C isn't as good as you might think for a new programmer. The problem is that you don't get very far with it at all without having to deal with pointers, and they're plain difficult to start with. (I didn't grok pointers until I'd first understood both addressing in assembly and references in Pascal, and even then it took me a while to get fluent. Being stuck on a segmented architecture didn't help though...)
I recommend a scripting language of some kind. Preferably one that gives an interpretive loop so that you can have an idea and try it out immediately; that's very rewarding and makes it easy to learn by mistakes. Compiled languages can come later. (I don't know when to introduce the high-power concepts like objects and pointers and stuff like that; it might be better to let them start to hit the limits of doing stuff the simple way before unveiling the deeper mysteries.)
You're dead right to avoid C++. That's a language that really isn't beginner oriented in any way at all.
Later I wrongly presumed my niece, who was a sharp book-reading kid of the mouse generation, would become the 'IT support staff' of her home & I could stop handling that. Didn't work out that way. Despite daily use, she's a decidedly non-technical average user. I've remained the 'tech' guy for family and friends, more than half of which grew up with the mouse now.
Smart kid to avoid getting stuck in a tech support role. Kudos to her.
The usual cheating is to pretend to "compress" the data, but actually hide it some other place on the machine.
So you get a smaller filesize, and it decompresses alright too.
But copy the "compressed" file to another machine without copying the hidden data and it "fails" to decompress.
It's better than that. If you're using NTFS or HFS+, you can squirrel the data away in an Alternate Data Stream/Resource Fork and the data will be copied around with the file. In a real sense, it is part of the file and yet not. Might even get copied to another machine if the medium was a suitably-formatted device (not sure about that).
It wouldn't be difficult to put a torrent backend on HTTP, wherein the URLs would actually just be trackers for the peers, but dynamic content obviously couldn't be served in any practical manner this way. And usually serving static content is just a solved problem - bandwidth is cheap (until someone DoS's S3, anyways).
It's called a Content Delivery Network, and they have been in use transparently for over a decade. If you didn't notice, that's good. A full P2P CDN could be made to work, but has many awkward deployment issues (e.g., most of the downloading endpoints really don't have a lot of upstream bandwidth) so the traditional model is likely to persist since it's a proven model at both technical and business levels.
The treatment in Dragon Age: Origins seems pretty good. It's clear that it has been informed by Christianity (in all its morally-ambiguous sometimes-schismatic glory) but is also clearly something else so people don't need to get too offended. Within the game it has the benefit too of not being a mechanistic thing, but rather a motivating force for many of the NPCs. It's also had a bit of effort put into the sacred texts.
I don't see any ads at the top of search results. Am I blind? All I see are useful links to other sections of Google I can search with, like images, which I use quite often.
It depends on what you search for. If you were to search for "used car" then you can bet there would be ads. If you were to search for "clojure rexx comparison" then there wouldn't (I've just checked).
Another example: I want my users to type in my domain and drill down to pages. This gets me maybe 3 or 4 pageviews. Coming in straight from google gets me one pageview. See how this could get someone upset?
On the other hand, that one pageview will be of what the user wants so they are likely to keep looking at it for a while and they will think about the content. All those other views from the other model were representative of users' frustration, of things that were in the way of users getting what they want. That means that that one view is more a more valuable one to you as it represents a more satisfied (and receptive to advertisements) consumer of your content.
If you truly think that pageviews are a measure of how good your site is, then you'll ignore what I say anyway. On the other hand, there are other metrics that are probably better (e.g., number of unique users, number of visits per user).
The person who knowingly sells parts or software or equipment to the government is attempting sabotage.
I assume you left out the word "defective" there (or something like it)? Otherwise you're trying to criminalize people for just honestly selling ordinary stuff to the government. Even for a dyed-in-the-wool libertarian, that's a little extreme.
If it were that simple then the makers of such machines wouldn't be so reluctant to explain how they actually work. In many places, though possibly not here, a blood or urine test is required.
The cops probably don't know how they work. (Can you exactly explain how everything you use works? Really?) But they do know just what constitutes evidence for the jurisdiction, and picking a fight over it is just plain dumb.
they don't actually prove you've had alcohol or that are intoxicated
But they do nicely establish probable cause for a blood test, and the #1 reason for failing the breath test is intoxication so even without a blood test you've got a fair mountain to climb to establish that there is reasonable doubt. If the police officer has video footage of you coming out of a bar or driving erratically, well, perhaps you should have stayed sober after all? Or got a taxi?
You're absolutely right. If only the broadband providers were truthful in advertising what their oversubscription rates were. Might as well be up front about it.
Did you pay for a QoS guarantee? No? Does the contract with your ISP include the phrase "up to" in the small print? Yes? You've got no room to complain. You've just not bought that headline rate for 24/7. Now if you're only using the network in a bursty fashion, which almost all home users do, then the chance is you'll actually get the transfer rates advertised (as constrained by the physical properties of the link). The same principle - stochastic multiplexing - was used back when Ethernet was invented at the Xerox PARC. The other issue is that most home networks have much more downward bandwidth than upward. If someone saturates that with bittorrent traffic (an example of a protocol and client-set that really assume balanced dedicated networking bandwidth) then lots of people get inconvenienced.
Now, since your whining about it won't change anything (you won't get better QoS without paying more) why are you bothering to sound like a grumpy old man? Maybe you'll eventually get them to add a bit more small print to the ads...
Been there, done that. Sadly the only way to see how your setup works is to try it in production.
The other thing to mention is to be honest with the other technical staff about if you've actually made a change, even if "trivial". This is because sometimes when you modify something, you can end up dumping them in the shitter accidentally, e.g., by putting a critical service on the wrong side of an internal firewall so that no packets get routed to it at all. In fact, I saw that once and networking stonewalled for a week before admitting that indeed they had made a small modification "that shouldn't have affected anything" and which cost quote a lot of lost work. By being honest and humble, they'll cut you more slack later if/when the boot's on the other foot.
OTOH, if management are insisting that all communications get routed through them, you're screwed. (NB: that's not the same as managers getting Cc'ed.)
Also, as you can't trust the module developers for maintaining compatibility, to tell a sysadmin to install the latest release of this list of 15 modules would give you headaches for support.
Unless something's changed from the version of the docs that Google found, Perl assumes that if you want version X of a module then any Y > X will also do. That makes it difficult to have multiple versions of a module without @INC games. It also only applies the version check after the module is already required; it doesn't apply it when deciding which file to load in the first place. That's just too damn late and makes the @INC games worse.
Right now, Perl essentially assumes that, for each module, everyone on the system uses the same version or does something nasty and system-specific to hack around it. Meh.
Where I work at they get around this by installing differing versions of each module into it's own directory and having a core installed module load up the appropriate paths in @INC at compile time. All it requires is the scripter specify which modules they need and what versions of those via the 'use' statement.
Part of the problem is that Perl's handling of module versioning is a bit half-assed. In particular, there's no support for having several versions of a module installed and the script selecting which to use (e.g., all 1.X are OK when X is more than 4, but 2.Y are no good because the API changed incompatibly). Right now, if there's two versions on the @INC path then it's pretty random which one you'll get (well, it will be the first on the path) and so scripts can't handle module API versioning over the long term. (Except by putting the major version number - i.e., the basic API version number - in the module name, which is a nasty hack.) Managing it all by manipulating the @INC path is crappy, because there's no particular reason for the modifications to be portable (and some of us like to write portable code).
If you could state the version number requirements of modules more exactly, then system scripts could lock down to known-acceptable versions much more easily while allowing user scripts to move ahead without so much trouble. (Not that I think it is easy for things to get there from here; changing the versioning habits is inevitably painful, even if it is for the best...)
If you only have a single task to do, and weeks to do it, then you are 1) not being very prducttive, and 2) selling yourself short.
Different people switch tasks at different speeds. Fast switchers (yourself perhaps?) are best off moving between different projects doing lots of things. Slow switchers (the GP?) are best kept on one task for quite a long time, but are usually able to produce better solutions precisely because they spend more time on the problem. The world has both types of people and its important to remember that what works for you might not be good for others.
This is how I develop, and it works very well. My peers and managers are happy, because I am productive. I am happy because I don't feel like I'm procrastinating for long periods. Too much 'sitting on your hands' is boring, it makes the days drag on, and is not really helping you write good code. For me, that is what job satisfaction is all about.
Be careful of burning out there. Get yourself too tired and you'll be unable to do anything at all; your ability to focus just goes and your productivity ceases to exist. This is why weekends off and vacations are important.
Yes. Unfortunately U.S. laws are usually written to favor corporations at the expense of individuals.
Actually, they're (mostly) written to pretend that there is no difference between people and corporations. If you think these two classes of entity are one and the same, clap your hands together and say "I believe in bailouts!"
Slashdot Mirror
Federal rail regulations being what they are, the only prospect for high speed rail is if the entire system is grade separated - that is, there are no at-grade crossings.
Experience with high-speed rail in Europe indicates that you really don't want at-grade crossings. They're just massively dangerous, especially with trains going at over 200kph. You also want to put stout fencing around the line to keep out vehicles that aren't supposed to be there in order to prevent accidents.
I often wonder why high-speed rail couldn't be built in the empty median of interstate highways.
The key problem is that most of the places you really want to build high-speed rail (i.e., relatively densely populated regions) you're much less likely to have enough room in the median. Sure there's plenty of room in the midwest, but there's also not the population density to make investing in high-speed rail lines there. (Well, not for now. No point in worrying about things too far off in the future though.)
I'm no more into knocking mass transit than he ... was ... but I can no more help manipulating numbers than I can help breathing, and the numbers show that mass transit works well where you have heavy population density, which most of the USA does not.
He's very selective with those numbers, you know. In particular, he's not making any allowance for the fact that one railcar can carry a lot more people than one automobile.
But to your main point, you should note that building fast rail in the US is sensible, but building a fast transcontinental service that serves ever settlement along the way is not. If someone's going from NYC to LA, they should fly. It's the short-range inter-conurbation hops that ought to be done more often by high-speed express rail. (Moreover, when you see actual plans of what people want to do, instead of pipe-dreams by people who aren't involved, it's those sorts of situations where action is really proposed. <sarcastic> It's almost like someone involved is an engineer with a clue. Funny that. </sarcastic>)
There's also at least a small chance that many of the kernel hackers who work on Linux today would have been working on the Hurd kernel.
I doubt it would have happened. The Hurd hackers wanted to do fundamental OS research, and everyone else wanted a "Unix" kernel that they could just use and hack around with, and which didn't cost a lot.
I can remember that the biggest factor in our little group of hackers moving to Linux (from 386BSD) was that it had working shared libraries. OK, they sucked in many (many!) ways, but it still meant that you didn't need to have loads of copies of libc in memory or on disk at once. On the small machines of the time, that was a massive saving.
There was an ad masquerading as an article by Michael Krigsman the CEO of Asuret, Inc., a software and consulting company dedicated to reducing software implementation failures.
I've found a workaround. I didn't read the article.
Victory #1: You're using version control!
Victory #2: You're using something distributed!
Actually, there's a level of victory between those two: a version control system that can manage addition and removal of directories. That was another key step forward of CVS over RCS. (Really. I remember using RCS and I won't ever go back there.)
For small businesses with a single point of contact, maybe cloud storage is fine. However, for bigger businesses, it is better off to just go with a d2d2t solution, and offsite backups. This way, data is physically protected from compromise, but is stored redundantly.
You're right about small businesses. They typically won't have a dedicated sysadmin at all; the owner, owner's spouse, or (in a slightly larger business) secretary will occasionally look after the computer(s), but they won't be able to carry the overhead of a dedicated tech support staff. For these sorts of firms, any backups are a good step forward and backups to the cloud have the benefit of not being so inclined to be lost in a fire.
As the size of business considered increases, your suggestion of d2d2t2offsite is reasonable (for backup; the Cloud's about much more than just backup of course). However, even that doesn't scale up too well. For big corporations, managing datacenters is a significant problem and for almost all of them, it's not their core business. For them, the cloud is a good choice once again since it lets them expand without having to build (or acquire) and provision new datacenters. It's about outsourcing. It's about flexibility. It's about accountability[*]. It's about the realization that keeping everything in house doesn't necessarily help; they need a data security compliance officer with authority to kick butt and stop crap providers from being used, but they need that sort of position anyway. They might not have it, of course; many businesses are not very well run. No change there...
I wouldn't put my private data up even onto a cloud of a company I trust completely.
And you're going to pay to maintain your own hardware and software installations as an upshot of that choice. As long as you're willing to deal with the consequences, your decision is fine. The only time there's a problem with the cloud is when you're forced into using it for your private data because there's no choice. (But then again, that's generally when there's a monopoly about instead of a free market...)
BTW, successful cloud providers are probably more likely to take good care of your data than some random corporate datacenter. For one thing, the cloud providers have to have competent and security-aware technical staff. All you need to have to own and run a datacenter is a building with enough power, AC and networking, and someone who can plug a rack in.
There's nothing particularly wrong with plain C as a first language. (I'd avoid all the intricacies of C++ syntax for a first-timer. The OO stuff is, in my opinion, totally unnecessary for a first-time programmer to learn.)
Plain C isn't as good as you might think for a new programmer. The problem is that you don't get very far with it at all without having to deal with pointers, and they're plain difficult to start with. (I didn't grok pointers until I'd first understood both addressing in assembly and references in Pascal, and even then it took me a while to get fluent. Being stuck on a segmented architecture didn't help though...)
I recommend a scripting language of some kind. Preferably one that gives an interpretive loop so that you can have an idea and try it out immediately; that's very rewarding and makes it easy to learn by mistakes. Compiled languages can come later. (I don't know when to introduce the high-power concepts like objects and pointers and stuff like that; it might be better to let them start to hit the limits of doing stuff the simple way before unveiling the deeper mysteries.)
You're dead right to avoid C++. That's a language that really isn't beginner oriented in any way at all.
Later I wrongly presumed my niece, who was a sharp book-reading kid of the mouse generation, would become the 'IT support staff' of her home & I could stop handling that. Didn't work out that way. Despite daily use, she's a decidedly non-technical average user. I've remained the 'tech' guy for family and friends, more than half of which grew up with the mouse now.
Smart kid to avoid getting stuck in a tech support role. Kudos to her.
The usual cheating is to pretend to "compress" the data, but actually hide it some other place on the machine.
So you get a smaller filesize, and it decompresses alright too.
But copy the "compressed" file to another machine without copying the hidden data and it "fails" to decompress.
It's better than that. If you're using NTFS or HFS+, you can squirrel the data away in an Alternate Data Stream/Resource Fork and the data will be copied around with the file. In a real sense, it is part of the file and yet not. Might even get copied to another machine if the medium was a suitably-formatted device (not sure about that).
It wouldn't be difficult to put a torrent backend on HTTP, wherein the URLs would actually just be trackers for the peers, but dynamic content obviously couldn't be served in any practical manner this way. And usually serving static content is just a solved problem - bandwidth is cheap (until someone DoS's S3, anyways).
It's called a Content Delivery Network, and they have been in use transparently for over a decade. If you didn't notice, that's good. A full P2P CDN could be made to work, but has many awkward deployment issues (e.g., most of the downloading endpoints really don't have a lot of upstream bandwidth) so the traditional model is likely to persist since it's a proven model at both technical and business levels.
The treatment in Dragon Age: Origins seems pretty good. It's clear that it has been informed by Christianity (in all its morally-ambiguous sometimes-schismatic glory) but is also clearly something else so people don't need to get too offended. Within the game it has the benefit too of not being a mechanistic thing, but rather a motivating force for many of the NPCs. It's also had a bit of effort put into the sacred texts.
I don't see any ads at the top of search results. Am I blind? All I see are useful links to other sections of Google I can search with, like images, which I use quite often.
It depends on what you search for. If you were to search for "used car" then you can bet there would be ads. If you were to search for "clojure rexx comparison" then there wouldn't (I've just checked).
Another example: I want my users to type in my domain and drill down to pages. This gets me maybe 3 or 4 pageviews.
Coming in straight from google gets me one pageview.
See how this could get someone upset?
On the other hand, that one pageview will be of what the user wants so they are likely to keep looking at it for a while and they will think about the content. All those other views from the other model were representative of users' frustration, of things that were in the way of users getting what they want. That means that that one view is more a more valuable one to you as it represents a more satisfied (and receptive to advertisements) consumer of your content.
If you truly think that pageviews are a measure of how good your site is, then you'll ignore what I say anyway. On the other hand, there are other metrics that are probably better (e.g., number of unique users, number of visits per user).
The person who knowingly sells parts or software or equipment to the government is attempting sabotage.
I assume you left out the word "defective" there (or something like it)? Otherwise you're trying to criminalize people for just honestly selling ordinary stuff to the government. Even for a dyed-in-the-wool libertarian, that's a little extreme.
If it were that simple then the makers of such machines wouldn't be so reluctant to explain how they actually work. In many places, though possibly not here, a blood or urine test is required.
The cops probably don't know how they work. (Can you exactly explain how everything you use works? Really?) But they do know just what constitutes evidence for the jurisdiction, and picking a fight over it is just plain dumb.
they don't actually prove you've had alcohol or that are intoxicated
But they do nicely establish probable cause for a blood test, and the #1 reason for failing the breath test is intoxication so even without a blood test you've got a fair mountain to climb to establish that there is reasonable doubt. If the police officer has video footage of you coming out of a bar or driving erratically, well, perhaps you should have stayed sober after all? Or got a taxi?
You're absolutely right. If only the broadband providers were truthful in advertising what their oversubscription rates were. Might as well be up front about it.
Did you pay for a QoS guarantee? No? Does the contract with your ISP include the phrase "up to" in the small print? Yes? You've got no room to complain. You've just not bought that headline rate for 24/7. Now if you're only using the network in a bursty fashion, which almost all home users do, then the chance is you'll actually get the transfer rates advertised (as constrained by the physical properties of the link). The same principle - stochastic multiplexing - was used back when Ethernet was invented at the Xerox PARC. The other issue is that most home networks have much more downward bandwidth than upward. If someone saturates that with bittorrent traffic (an example of a protocol and client-set that really assume balanced dedicated networking bandwidth) then lots of people get inconvenienced.
Now, since your whining about it won't change anything (you won't get better QoS without paying more) why are you bothering to sound like a grumpy old man? Maybe you'll eventually get them to add a bit more small print to the ads...
Been there, done that. Sadly the only way to see how your setup works is to try it in production.
The other thing to mention is to be honest with the other technical staff about if you've actually made a change, even if "trivial". This is because sometimes when you modify something, you can end up dumping them in the shitter accidentally, e.g., by putting a critical service on the wrong side of an internal firewall so that no packets get routed to it at all. In fact, I saw that once and networking stonewalled for a week before admitting that indeed they had made a small modification "that shouldn't have affected anything" and which cost quote a lot of lost work. By being honest and humble, they'll cut you more slack later if/when the boot's on the other foot.
OTOH, if management are insisting that all communications get routed through them, you're screwed. (NB: that's not the same as managers getting Cc'ed.)
Also, as you can't trust the module developers for maintaining compatibility, to tell a sysadmin to install the latest release of this list of 15 modules would give you headaches for support.
Unless something's changed from the version of the docs that Google found, Perl assumes that if you want version X of a module then any Y > X will also do. That makes it difficult to have multiple versions of a module without @INC games. It also only applies the version check after the module is already required; it doesn't apply it when deciding which file to load in the first place. That's just too damn late and makes the @INC games worse.
Right now, Perl essentially assumes that, for each module, everyone on the system uses the same version or does something nasty and system-specific to hack around it. Meh.
Where I work at they get around this by installing differing versions of each module into it's own directory and having a core installed module load up the appropriate paths in @INC at compile time. All it requires is the scripter specify which modules they need and what versions of those via the 'use' statement.
Part of the problem is that Perl's handling of module versioning is a bit half-assed. In particular, there's no support for having several versions of a module installed and the script selecting which to use (e.g., all 1.X are OK when X is more than 4, but 2.Y are no good because the API changed incompatibly). Right now, if there's two versions on the @INC path then it's pretty random which one you'll get (well, it will be the first on the path) and so scripts can't handle module API versioning over the long term. (Except by putting the major version number - i.e., the basic API version number - in the module name, which is a nasty hack.) Managing it all by manipulating the @INC path is crappy, because there's no particular reason for the modifications to be portable (and some of us like to write portable code).
If you could state the version number requirements of modules more exactly, then system scripts could lock down to known-acceptable versions much more easily while allowing user scripts to move ahead without so much trouble. (Not that I think it is easy for things to get there from here; changing the versioning habits is inevitably painful, even if it is for the best...)
If you only have a single task to do, and weeks to do it, then you are 1) not being very prducttive, and 2) selling yourself short.
Different people switch tasks at different speeds. Fast switchers (yourself perhaps?) are best off moving between different projects doing lots of things. Slow switchers (the GP?) are best kept on one task for quite a long time, but are usually able to produce better solutions precisely because they spend more time on the problem. The world has both types of people and its important to remember that what works for you might not be good for others.
This is how I develop, and it works very well. My peers and managers are happy, because I am productive. I am happy because I don't feel like I'm procrastinating for long periods. Too much 'sitting on your hands' is boring, it makes the days drag on, and is not really helping you write good code. For me, that is what job satisfaction is all about.
Be careful of burning out there. Get yourself too tired and you'll be unable to do anything at all; your ability to focus just goes and your productivity ceases to exist. This is why weekends off and vacations are important.
Yes. Unfortunately U.S. laws are usually written to favor corporations at the expense of individuals.
Actually, they're (mostly) written to pretend that there is no difference between people and corporations. If you think these two classes of entity are one and the same, clap your hands together and say "I believe in bailouts!"
Of course, Microsoft has been in this business for a long time so they can give lessons to Verizon.
Looks to me like they're in an evil-ness sharing agreement with Satan acting as a personal go-between.