Take a long vacation some time. Even if you do have a family, save up enough money and go travel for a while. Take some decent time off work (4+ weeks). Let them fire you if they want. That's (one of my) my goal(s) over the next 2 years: take an extended vacation (I haven't taken more than a week off since I graduated college).

In Germany and many European countries, you pay for healthcare and it costs a lot -- you simply don't have the option of not having healthcare and the cost is proportional to your income rather than your health condition. Also note that the employee caries the full cost of health insurance as opposed to the employer usually covering it in skilled professions in the US.

The social security model is also somewhat similar: you pay (high) social security taxes and get money back based your contributions.

Unemployment, also like in the US, is pretty sane if you're a full-time employee and are fired. You don't get it for several months if you quit on your own and if you haven't payed unemployment taxes, you get put on unemployment that's just at the edge of livable (housing costs + about $500/month).

And note, those taxes come after the lower salary. A pretty common take-home salary for a European software developer would be $3000-4000/month.

And really, how many 20-somethings that complain about the cost of living are doing it because they're stashing away too much in their retirement fund?

Public transit is a valid one, but then, the two highest paid areas for software developers in the US, New York and San Francisco, also have quite good public transit. (Not to mention that a one-month pass costs $100-200/month depending on the area.)

The truth is that I've heard people say that while they eat out every day, have a new car every couple years, live in swanky places and spend money on a constant stream of new gadgets. Americans also have a weird fetish that you don't find other places about buying homes in their 20s. While there are some valid reasons that make the total cost of living in Europe comparatively lower, I'm really not convinced that's the core of the difference. It's just that people quickly grow into their incomes and start seeing things as essential that aren't.

DRM has now made movies suck even at the theater. If I was a director, I'd be cheesed.

Force.

As in, my employer is forcing me to take shorter vacations. My employer is forcing me to work my vacations around their schedule.

That's not what he's doing. He's coercing you. It's different. He's implying that if you take the vacation you want, there might not be a job waiting when you get back. The answer to that is "fine".

If you truly don't care whether there's a job waiting on the other side, he loses all leverage. If you know for a fact that you could pick up another dev job inside of a week with a Facebook status update, he loses all leverage.

In other words, the only reason you think your boss can "force" you to do anything is because you've given him that ability. Quit thinking in those terms and you'll live a much happier life.

That said, most Americans wouldn't like the European pay scales. While a developer gets 3-6 times the vacation in Germany, they make half as much money.

For me it was a great trade; I still had a middle class income and spent my 20s bouncing around the world visiting more than 30 countries on 5 continents, with zero gaps in my employment.

Now that I'm an employer, I still see it as a great trade: employees are a lot cheaper here, and seem to be happier. But again, while most American software developers would love to have more vacation, I've heard them also repeat ludicrous things about how they can "barely survive on $60k/year".

Many employers also lump in sick time with vacation time, as if that's a replacement since you didn't come into work. That would probably be okay, if you had an option to take unpaid vacation time when the time comes. Instead, you're often forced to take a shorter vacation, which doesn't do the job.

And forcing you to work while on vacation is unforgiveable. It shows that the company doesn't understand why vacation time is necessary. (I haven't had anyone do this to me, thankfully. It wouldn't have gone well.)

If taking unpaid vacations was an option, I would probably end up taking about 4 weeks worth of vacations, instead of 2.

1. Nothing in the letter commits Apple to defend the developers or to hold them harmless. Legally, Apple does not have to do this. One can only hope that its self-interest in protecting its app-store ecosystem will be enough to cause it to do what is right. For now, Apple is saying only that it will fully defend its "license rights." One can read more into this than is stated but that is all that is stated (of course, Apple's throwing its weight behind developers even at this level is no small thing).

2. The letter does not quote the license agreement in any way. Normally, if there is something definitive in such a document, it is put front and center in a letter of this type. This could mean that the license language is not as definitive as the tone of this letter might suggest. Only time, and a detailed review of the license language itself, will tell on this point.

3. It is plain that Apple wants to do the right thing for its developers. Yet the situation is trickier than that. As of now, Apple has no legal obligation to defend or hold them harmless, and that step is an order of magnitude greater than that of saying it will merely defend its license rights - and hence the hedging in the letter.

If the goal of the patent system is to promote innovation, then this case is Exhibit A for how it is failing. Thousands of patents are gathered up in a portfolio held by an IV affiliate and licensed in bulk ("monetized") to big players such as Apple, Microsoft, Google, etc., who in turn believe that they have clear rights to build systems around them. But the patents are "monetized" again to lesser players with shadowy relations to the original IV group, who in their turn try to "monetize" them further by attempting to double-dip with the original licensees based on limitations in the original licensing language. At each step, threats of lawsuits abound and nowhere can one find even one example of a patent developed by a company for its own innovative uses. Instead, we have the equivalent of shadowy trafficking in intangibles that are now being used, not to encourage innovation, but to attack the very developers who are trying to innovate. Positively Kafkaesque.

Speaking as someone who has worked on this problem for my own projects [1], I think I can answer this.

Fedora/Yum already supports downloading a binary diff between rpm packages to reduce download size, but this also requires keeping a cache of previous rpm's to run the patch against. There are multiple reasons why you can't rely on binary diffs against the files actually stored on the system, most namely for files like /etc/* that are more than likely modified since installation.

But the real problem with binary diffs is that unless you're doing what Google does to ensure that people stay up to date, the number of binaries you need to diff against grows very quickly, and there are a lot of edge cases to take care of.

For example, let's assume some package A has been released as version 1, 2, and 3. When A has a new release 4, you obviously want to build a diff against release 3, but then you also most likely need or want to build a diff against 2 and maybe even 1 to take care of people who haven't already upgraded to 3. And even if you build a diff against every single version ever released, you will still always need to provide a full version of the package as well for two cases:

1. New installations, or reinstallations, of the package.

2. When the user has cleared their package cache to save room.

And even beyond that, creating diffs involves a lot more effort and knowledge on the part of the packaging team because they not only need to know how to build those diffs, but they also need to keep track of old package versions to build those diffs against.

The end result is that you trade download bandwidth and time on part of the server and end users for a lot of effort, time, and storage space on part of the packagers and distro mirrors. For mirrors that are already encroaching on 50GB for a single release of Ubuntu and/or Fedora, adding a whole bunch of binary diff packages will most likely grow the repository size by at least 30-50%, if not more, depending on how many old versions you diff against.

The question then becomes: does this trade off actually make sense, or does it present further roadblocks for contribution from packagers and donated mirrors?

[1]: If you would like to see how I handled this sort of task, I have a Python library I wrote to handle the client side updating. I know it's not the entire piece of the puzzle because it doesn't cover generating the updates, but it might be useful for someone else. http://github.com/overwatchmod/combine