Beer should be served at room temperature (not warm). If it needs to be chilled, which reduces the sensitivity of the tastebuds, then the correct solution is to buy better beer.

It's also redundant and likely not to do the right thing (ironic, given previous comments about libraries). Look for latexmk, which is part of the standard LeXLive distribution. Oh, and since this is not 1970 anymore, let's skip the DVI step and go straight to PDF with pdflatex (latexmk -pdf manuscript.tex is probably what you actually want).

The Dalek suits were originally inspired by female dancers gliding along the ground in long skirts, so there may be even more to it than you think...

If you're a photographer dealing with 30MB images, then you're almost certainly using non-destructive editing on them. It sounds like the tool that you want is not a version control system at all, it's a filesystem.

You can checkout a subdirectory if (and that's a big proviso) you structure your code in such a way that each directory is a separate git repository, referenced as a submodule. The submodule points to a specific version of the other repository. Unfortunately, there are still a lot of issues with this approach:

The biggest is that you have to think about what parts of the project you might want to check out individually before you start. For new (small) projects, it's sometimes easy, but typically projects grow organically and parts get factored out. There's no good way of turning a subtree in a git repo into a new repo preserving history (and no way at all that allows you to merge into both).

The second big one is that you lose atomic commits (the thing we all switched to svn from cvs for in the first place). If you only have one layer of submodules, it's quite nice because committing something to the submodule and updating the version of the submodule are independent. That means that you can make changes to a component, unit test them, commit, and then later update their consumers. Unfortunately, there's no way of atomically updating two independent subtrees simultaneously.

The third annoyance is the most embarrassing for a DVCS: the remote repository for upstream is identified by an absolute URL. You can do relative URLs, but they don't work very well, which means that if you want people to use a local version then it's quite convoluted. There's no simple 'clone this repo and all of the submodules in such a way that someone else can clone my copy and it all work sensibly'.

In general, the dire UI of git has been an unexpected advantage. No one can stand working with it, so people have been motivated to write nice GUIs that make it tolerable.

Freescale mostly sells PowerPC chips for automotive and similar applications. They already had the low power parts, but they didn't have them at the speeds that Apple wanted. Most of their customers use their chips for engine control or entertainment systems. They also made the chips for consoles. Their biggest weakness was that Apple was the cheapest supplier of a PowerPC system that you could develop on, and they were undercut by a long way by Intel machines. This is the same problem that Alpha had: it didn't matter that their Windows NT systems were faster than Intel's, they didn't get them into the hands of developers so everyone wrote software for Intel.

Okay, so I'll take this as "urban legend" until you can find backing.

So, I see this as rationalization.

The fact is, you took a leadership position, and later turned your coat for reasons that perhaps made sense to you. But they don't really make sense to anyone else. So, yes, everyone who supported you then is going to feel burned.

You also made yourself a paid voice that was often hostile to Free Software, all the way back to the SCO issue. Anyone could have told you that was bound to be a losing side and you would be forever tarred with their brush.

So nobody is going to believe you had any reason but cash, whatever rationalization you cook up after the fact. So, the bottom line is that you joined a list of people who we're never going to be able to trust or put the slightest amount of credibility in.

And ultimately it was for nothing. I've consistently tried to take the high road and it's led to a pretty good income, I would hazard a guess better than yours, not just being able to feel good about myself.

Meh, it's easy to find people with skill. With values, OTOH...

You have a point.

It's sort of a chicken-and-egg issue. Debian doesn't get the help because Debian doesn't make itself worthy of getting the help. There have previously been paid developers working on Debian, they simply weren't paid by Debian.

That is, of course, for a given radiation dose, which is independent of body cross section - which is relevant in real-world scenarios. If we assume an isotropic radiation exposure profile, an average male height of 174cm, an average female height of 161 cm, and asssume an equivalent profile, then a man presents a 17% higher profile to radiation exposurediation exposure, so if a woman has a 50% higher (150%) cancer risk, then it's only 29% higher for a fixed radiation flux per square meter.

However, let's look further at this. Given the smaller size of members of a female crew, you can shrink the spacecraft occupant space by 8% on each axis, or a volumetric decrease of 26%. Mass changes are more difficult to reckon. Life support, food, water, etc is dependent on metabolism, which the article shows is dramatically lower for women in space. Fuel needs are proportional to all other mass issues. Only a few things (such as computers and scientific equipment) don't trace back to crew member size and mass. Regardless, for a given launch weight, it's clear that you can afford the mass of a significantly increased amount of radiation shielding for a female crew due to the weight savings elsewhere, probably easily more than offsetting the cancer risk.

Beyond this, the average US astronaut age is 34, an age well after when most women are done having children (assuming that they even want to have children). Given that the article states the risk is from breast, ovarian, and utirine cancer, I wouldn't be surprised if many would consider full hysterectomy for the ability to travel to Mars.

I love the fact that Mars is the only planet known to man that is solely inhabited by robots

Despite how radical that statement sounds, it's actually perfectly reasonable for a zero-G environment. They're not only dead weight, they're also in the way and make you require larger accomodations.

Even in Mars's gravity field a legless person would deal quite well, at least inside the facility (picture how easily you could get around without your legs if you suddenly were given 2.5x the arm strength, didn't have your legs weighing you down, and on top of that add in how most double amputees already have good arm strength to begin with). They should be able to "hop" with their arms all the way to a 2 1/2 meter ceiling without trouble, and the full arc would take a good two seconds to come back down. On the moon it'd be even easier. Of course, if they're legless, why would they even need such tall ceilings to begin with?

Citation so we know what you're talking about?

I am beginning to be wary of systemd, but no. I am talking about anal-retentive policy wonks who believe they only make the distribution for themselves and have (perhaps without intending to) systematically marginalized Debiian and made the project a whore to Ubuntu.