I work for a consulting firm and when I can do development on my employer's laptop rather than using a client provided device, I always spin up a VM and install any required software. I often have to use client-specific VPN software, and running it in a VPN keeps it off my employer's machine. It also makes clean up easy after I complete a project.

Buck Woody blogged about this over a year ago. http://blogs.msdn.com/b/buckwoody/archive/2013/10/16/free-built-in-steps-recorder-in-windows-for-training-demos-and-documentation-oh-and-troubleshooting-too.aspx"

Why not just buy the CD? Then you can rip the songs to whatever format you want and use them on whatever device you want.

I understand. My situation was as a salaried employee who worked 7 days a week, 12+ hours a day, for two months straight. It stopped at 2 months because I took a previously scheduled vacation. When I returned it was more of the same with a few weekends off.

When I came to that same conclusion at a job, I found another job.

Bonuses? You mean the $50 gift card to a restaurant I got after working 12+ hours a day, 7 days a week for 2 months straight? On my subsequent annual review, I was told I was the best developer they had and because of that, I was getting a raise .5% higher than average. I left not long after that.

I'm inclined to disagree about CP casting its net too wide. There are so many technologies out there just in the Microsoft world, that it's next to impossible to even be aware of them all, let alone be knowledgeable about them. I have come to CP both for 101 level information on technologies and for help when I'm having difficulty with some obscure feature of a technology. I'd hate to live with just MSDN as a source of information. Yes, some articles aren't very well written, but perhaps it's the author's first attempt at writing an article for an audience larger than their coworkers. When I read an article, I also read the comments and I pay attention to the ratings when I search for info on a topic. I have seen people post constructive criticism in the comments and I encourage others to do so.

Click? I wrote my first program on a Teletype creating a punched paper tape. It was done that way because it cost too much to develop it while connected to the timesharing service via an acoustic coupler. I think we had the high speed 300 baud version.

The idle loop on RSTS would make the console lights cycle in a clockwise direction. You could tell how busy the CPU was by watching to see how often and how long the idle loop display was interrupted. Once the system was down for a hardware failure, so we wrote and toggled in our own "idle loop", except it cycled the console lights in a counter-clockwise direction. We waited as other developers came into the computer room to see why they couldn't log on. Only one developer figured out there was a problem by simply seeing the console lights cycling backwards. The rest asked us if there was a problem.

I worked on an IBM 360/40 with 256k core memory. There were a few disks, but a majority of our work was done with tape. Do you remember how to do a master file update with the master on one tape drive and the updates on another tape drive with the new master going to a third tape drive? Needless to say, I preferred the PDP-11/20 I mentioned in another post.

Let's see, I've never done embedded programming so my limitations weren't too bad. On the PDP-11/20 running RSTS with BASIC-Plus, you had an 8KB address space for your program and data. Since it was interpreted, code comments took up space and thus were discouraged. Variable names weren't a space issue since they were limited to upper case letters A-Z, optionally followed by a digit, optionally followed by a type indicator: No type indicator was a floating point number, a type indicator of '%' was a 16 bit integer, and a type indicator of '$' was a string. Given the address space limitations, most programs were broken into one or more data entry programs which interacted with the user, did limited data validation, wrote the input data into a temporary file, and then passed control to another program, using the "CHAIN" keyword, that did additional validations, including file-based validations, and if everything was OK, updated the actual production data files. If there was a data problem, the program would CHAIN back to the data entry program with a link to a temporary file that had information about what was wrong with the data. The file system was equally primitive. You read and wrote 512 byte blocks of data from/to the disk. The rest was up to the developer. Some people wrote indexes which lived in separate files and sped up access. I wrote a hash-based lookup with collision detection and handling.

Reminds me of toggling in the bootstrap loader on the PDP-11/20.

I'm aware of a company that has > 10,000 MSDN licenses that last year downgraded everyone from Premium to Pro level subscriptions due to the cost of those licenses.

'The only time you have too much fuel is when you're on fire.' - Unknown Author That may true in military aircraft, but that is definitely not true in civilian aircraft. I was flying a particular low wing aircraft that I rarely flew and stopped for fuel at an airport. The line guy asked if I wanted the tanks filled "to the tabs" and I replied, "No, full please." In many smaller civilian aircraft the engine doesn't have enough power to take off with both full fuel tanks and passengers in all the seats or with a lot of baggage. So the aircraft manufacturer installs tabs in the fuel tanks that are visible when fueling. When the fuel tanks are filled to the these tabs, that generally means the aircraft will have enough power to take off with passengers in all the seats and little or no baggage. In this case, I had one seat empty, the passengers all weighed significantly less than the standard weight used for passengers when calculating whether the engine has enough power to take off with passengers in all the seats and full fuel, and no baggage, so I told the line guy to fill the tanks full. When the aircraft had been fueled, I paid the fuel bill, and I was ready to go again, I got permission to taxi to the runway and was immediately given permission to take off. The runway was paved, a length commonly found at smaller airports, the airport was less than 1,000 feet above sea level, and it was a cool day, so there was no need to configure the aircraft for what is known as a "short field" takeoff. A short field take off gets the aircraft off the runway using as little runway as possible and the pilot flies at a specific speed so the aircraft climbs at the steepest safe angle possible to clear any obstacles that might be at the end of the runway. I configured the aircraft for a normal take off and opened the throttle. The aircraft started down the runway but it seemed to take a little longer than usual to get up to flying speed and when it did I lifted off the runway. The aircraft was climbing rather slowly and the trees at the end of the runway were getting larger and larger in the windshield instead of disappearing out of sight below the nose of the aircraft like they normally do. It was at that point that I realized that something was wrong. A quick check of all the gauges indicated the engine was developing full power and I was flying at the proper speed to climb at the best angle possible. I needed to climb more quickly or there was a good possibility we would end up in the trees. The only thing left to do w

I'm not aware of anything in the OP that isn't in the public domain.

"A superior pilot is one who uses his superior judgment to avoid situations which would require the use of his superior skill" That assumes that one gets the chance to use one's superior judgment. A friend, who is a CFI (Certified Flight Instructor), and his student pilot were in straight and level flight when they were involved in a crash that cost the student pilot her life and my friend spent over a year in the hospital and rehab. They were hit from behind by a much larger and faster aircraft which disabled the elevator and rudder of their aircraft rendering it uncontrollable and unflyable. Due to the subsequent actions of the pilot of the other aircraft I will simply say he was insufficiently punished for what he did.

The what?

You are forgetting that in most cases, these corporations have been given monopoly power by the government, guaranteeing them a profit. In return for this guarantee, they must accept some regulation by the government. It's not like another company can come along and put in their own infrastructure and compete with them.

In most cases these "property rights" are monopolies granted by various levels of government. I live in an AT&T monopoly area. If I want internet access, I must buy it from AT&T. When it comes to internet access, most people simply want a fast connection to the internet, just like any other commodity. ISPs and the various backbone providers are effectively commodity providers and they don't like that. It costs them the same to send a byte from Point A to Point B whether that byte is part of an email, a video, a VOIP call, or an IM. They want to use their monopoly power to make even more money. For example, several years ago the FCC had to smack down a small Telco/ISP because they were blocking all VOIP calls coming into their network unless they were going to a customer of their VOIP product. These companies will do all they can to protect their monopoly power. Just take a look at municipal Wi-Fi. When these monopoly companies were dragging their feet on providing municipal Wi-Fi, some cities got fed up with it and decided to build their own. These monopoly companies immediately went to the State government and in many cases, managed to get laws passed prohibiting cities from building their own Wi-Fi because, they claimed it was unfair competition. Imagine that, a monopoly complaining about unfair competition. Edit: removed extra word.

There are no such laws in the U.S. in right-to-work states. However, a union contract or other employment contract may specify that the employee be paid for notice pay whether they work it or not. Note that in I.T. in the U.S., employee contracts and union contracts are rare.