Rebase Considered Harmful

Today I was musing about different version control systems and merge algorithms. I’ve been thinking specifically about how I maintain Debian packages in Darcs. I tend to import upstream tarballs into one branch, and maintain the Debian packages in another, simply merging when a new upstream is released.

Now, there seem to be two prevailing philosophies on how to handle merges in this case. I’m thinking here about merges back to upstream. Say I want to contribute my Debian patches to them.

  1. Commit “clean” patches upstream. Don’t have a bunch of history — the fixing typos commits, the fixing bugs commits, or the merging to track new upstream releases. Just something like a series of diffs against the current head.
  2. Bring across the full history, warts and all, and keep it around permanently.

git encourages option , with its rebase option. Darcs encourages option (though some use its amend-record option to work more like ).

As I got to thinking about it, it occured to me that git-rebase would be very nice if you are going to use philosophy . In short, rebase will remove your local patches from a repo, update it to the latest upstream, then re-apply your local changesets — aborting to have you fix any conflicts. This is as opposed to a more traditional merge, where you add the upstream changesets to your local branch and then commit new changesets to resolve conflicts. (So a rebase would be totally useless in situation )

I got to thinking about this, and started wondering what would happen to people that I’m working with that in turn work off my branches. And sure enough, the git-rebase manpage says, “When you rebase a branch, you are changing its history in a way that will cause problems for anyone who already has a copy of the branch in their repository and tries to pull updates from you.”

I maintain, therefore, that git-rebase is evil and should be avoided. It only works for a situation where someone maintains a private branch of a project, never shared in any way except to submit patches to an upstream. Forget it if you have a team maintaining that branch, or want to post that branch online for others to help with (as I do with my Debian darcs package). Even if you keep it private now, do you really want to adopt a work process that forces you to keep it private forever, or else completely change how you work?

And this brings me back to the original question of patch philosophy. Personally, I dislike philosophy . I’d much rather have the full history of a change, warts and all. Look at the Linux kernel example: changesets that introduced bugs that made it into the official tree have their fixes documented, but changesets that introduced bugs that were fixed before being merged into the official tree could be lost to the public due to rebasing by submitters. Is that really what we want? I don’t think so.

With Darcs, tagging is very cheap and it is quite trivial to write an “apply a changeset bundle” script that makes a before tag, applies a series of patches, and makes an after tag. One could then run a darcs diff between the two tags to see the net effect on the repository, or could still look at the individual patches. (Or, you can avoid tagging and manually specify the “from” and “to” patches.) I find that a much better model: you can have it both ways. I’d think that most modern VCSs ought to support some variant on that, too.

And I think that git-rebase should be removed on the grounds that it encourages poor version tracking practices.

Haskell Time Travel

There is something very cool about a language in which the easiest, most direct way to explain how it solves a problem is to say, “When we pass the output of [this function] into the input for the oracle we are actually sending the data backwards in time. So when [the code] queries the oracle we get a result from the future.”

Sweet.

The story goes on to say, however, “Time travel is a very dangerous business. One false move and you can create a temporal paradox that will destroy the universe (which in this case means that the computation will diverge). When programming with values from the future, it is important never, never, to do anything with the values that might change the future. This is the temporal prime directive.”

Dial Tone

Yesterday I went to activate phone service out at the farm. It got me to thinking a bit about how things change, and how they stay the same, too.

Before I go on, I’ll have to say that every one of my history books is in storage, so if I get some details wrong, it’s because I’m not remembering correctly.

Anyhow, phone service came to our community via an unusual route about 100 years ago. It wasn’t Bell/AT&T or some other company that brought it there, as it was most places. I’m sure they figured that a small, scattered rural community would cost too much to support. So the community organized, built, and supported the phone system themselves.

Even today, roads around here can be impassible after a good rain. I’m sure that, in the early 1900s, before heavy road-maintaining machinery, things were worse — and, of course, transportation was a lot slower then anyway. There were real problems: getting the word out about funerals, being able to summon a doctor when necessary, or letting people know that church was cancelled because of too much snow.

People in the community saw a phone system as a real need. So did the churches, which have left a legacy that is still reflected in phone company territories today.

Once phone service arrived, it was used for all the things that people expected, of course. But it also proved to be an important part of the social fabric of the community. Since party lines were the norm, it was possible to announce things to every listening subscriber pretty quickly. Older people remember announcements of fresh fruit arriving at the grocery store, funerals, or other news of the day.

To place a call, you would pick up your phone and turn your crank. That caused a bell to ring at the telephone office, which everyone called “Central.” The operator would connect to your line and ask whom you wanted to talk to. The operator would then send the distinctive ring for your party down their party line, and patch — manually — your call through to them. And, if he was busy, the operator wouldn’t listen in on your conversation — but others on the party line very well might.

Central’s hours were published. If you were making a call in the middle of the night, you were going to wake up someone at Central to do it — plus everyone on the entire party line. So calls after hours were rare.

Fortunately, while some of the old Central operators were still around, some people in the community wrote down some of their stories.

There were some people in the community that were notorious for eavesdropping on other people’s conversations. Two brothers one time figured that they knew somebody was listening to their conversations, so they devised a code. One called the other, and said, “I’ll be going to McPherson in the morning for band practice.” That meant something along the lines of going to town to buy groceries.

A few days later, their prime suspect came up to him and said, “What on earth are you going to band practice for? I didn’t know you knew how to play an instrument!” Apparently she realized she was had when he burst out laughing uncontrollably.

The Central operators learned to know the habits of telephone users. Sometimes they would connect calls without even bothering to ask who people wanted to talk to — and seemed to always get it right.

The phone system supported itself for about 50 years. But as the rest of the world moved on provide direct dialing, this proved a controversial subject in the community. People liked having their operators. The people that worked at Central were everybody’s friend. They were people that were there, 24 hours a day, to assist with any emergency. They would gather volunteer firefighters to help fight a fire, or be able to spread community news quickly. This wouldn’t be available with the newer phone systems. How would the community be informed of events quickly now? Who would just happen to know whose house the doctor was at when he was urgently needed?

The change was resisted for some years, but eventually the finances of the telephone cooperative turned out to be in deep trouble. Operators grew to be much more expensive than automation, and in the late 1960s, the telephone cooperative was no more — sold to a phone company from a small town more than twice our size, and a for-profit company at that! Central no longer existed. I remember reading about this event — it seems people were sad about that for quite some time. They felt that they had really lost an important part of the community when Central went away. Some machine locked in a cabinet doesn’t care for people the way Central did. Even today, the older people in the community sound a little sad when they remember telephone modernization, and get the wistful look of somebody that has just remembered something that they miss.

The phone company that bought the system wasn’t an AT&T, though. It was a small, independent phone company. To this day, that phone company serves only the two communities. And it was this company that I called yesterday to establish service out at our house.

They had already upgraded our lines — over a mile of new copper, benefiting only us, at no charge to us — last fall. The box was already on the outside of the house. Just need to get it activated.

So I called the phone company. They said I needed to drop by their office and sign some papers. Uh-oh, I think — this is a bad sign. Sounds like a bunch of phone company bureaucracy.

But not so much. I went to the office and signed up. They asked the usual questions: name, address. Plus a few that bigger companies wouldn’t ask: who used to have service at that address? Of course, most people would know that answer in our community. I couldn’t have told you in Wichita, Dallas, or Indianapolis.

Then they asked when I’d like service to be activated. “As soon as possible,” I say, figuring that this would be a couple of weeks like it is with AT&T or Sprint. “Well, we probably can’t get out there for a couple of hours. Would it be OK if it’s on at about 3?” Yes, that would be fine!

Now, how about DSL? “Well, we’re a little backed up on that right now.” Uh-oh. Sprint took several weeks when they *weren’t* more backed up than usual. “So it’ll probably be Monday or Tuesday before we can get out there. Should I just have the installer call you and arrange a time when it gets closer?” Yes, that would be fine, too!

Now, how about finding a phone number.

Out comes a large paper book. Yep, paper. They paged through it, and told me that my grandpa’s old number would be available if I wanted it. I said yes — after all, we’ve got his old address, so might as well keep the same phone number. OK, no problem. She whips out some white-out, whites out grandpa’s name, and writes ours in. Done.

Now, do I want any optional services? Caller ID, call waiting, voicemail? How much is caller ID, I ask. $5 a month. We’ll try it for now. “OK”. A box was checked on the form and that was that. No high-pressure sales pitch on taking “the works” for some poorly-disclosed price, providing a ton of services I’ll never use and don’t want. No confusing “discounts” for having The Works and DSL at the same time.

Then I ask about an unlisted number, or at least an unlisted address. I figured that anybody that really wanted to be able to reach us will figure out how without using a phone book, and these things get in so many databases these days. Sprint charged almost $10/mo for a fully unlisted number, but only a few dollars a month to just keep our address off the directories.

Our new company charged 50 cents a month for a fully unlisted number. Done.

Now it’s time to pay for the first month’s fees and the setup. Oops, I’ve forgotten my checkbook in the car. No problem, the secretary says, I’ll watch your baby while you go get it! Jacob was with me, but had fallen asleep, so I brought him inside in his car seat. I went to get the checkbook — just out the door and close by. I was back in a few seconds later, and the secretary was already on the other side of her desk talking and playing with Jacob. “My baby’s 12 now,” she said, and for a second, looked like a person that was remembering Central.

Memories of Christmas, part 1

Merry Christmas to everyone today!

Today, and for the next few days, I’m going to write about some of my Christmas memories from earlier years. Then I’ll finish up with some photos from this year.

This post is about Christmas at home growing up.

One of the first signs of Christmas happened when my dad put up the lights on the outside of our house.

My brothers and I had (and still do) stockings that got one piece of candy per day during December, then got stuffed full when we opened our presents. The tree went up over the Thanksgiving weekend, and it was always a lot of fun to help with that.

On Christmas Eve, we’d always go to the program at church. It was the kids’ Christmas play. Church would be packed. On the way out, everyone got a gift sack with fruit (apples or oranges), some peanuts, and maybe some candy. Then we’d go home. Mom or dad would read the Christmas story from the Bible, and after a prayer, it was time to open presents. In addition to the regular presents, dad would always give us a large paper gift sack. It would usually have a 12-pack of pop and some sort of nut (peanuts, pastachios, or maybe peanut brittle).

Sometimes we’d all stand still long enough for a photo.

We’d usually stay up late into the night Christmas Eve and sleep in on Christmas day.

Renovation: Week 24

Wow! What a week. (Click here for all of this week’s photos) On Sunday afternoon, we walked into the house and saw this:

Yes, over the weekend, the cabinet makers had installed the cabinets earlier than expected! I never expected that I would get excited about kitchen cabinets, but I sure was. They look great.

My grandma’s china cabinet is back up in the dining room. They’ve removed the tile from the dining room, exposing the wood floor underneath. The floor restoration people have spent some time doing some patching already.

Doors and doorjams are starting to go in. Trim is arriving. And the wood in the wall alongside one of the staircases has been seamlessly extended.

It’s exciting. (photos here)

And check this out:

That hunk of ice is the exhaust from our furnace. No joke! The furnace is so efficient that, when its running, it’s a moist and slightly warm breeze blowing out of that exhaust pipe. In winter, it condenses and drips down below, forming an ice hunk.

Saving Power with CPU Frequency Scaling

Yesterday I wrote about the climate crisis. Today, let’s start doing something about it.

Electricity, especially in the United States and China, turns out to be a pretty dirty energy source. Most of our electricity is generated using coal, which despite promises of “clean coal” to come, burns dirty. Not only does it contribute to global warming, but it also has been shown to have an adverse impact on health.

So let’s start simple: reduce the amount of electricity our computers consume. Even for an individual person, this can add up to quite a bit of energy (and money) savings in a year. When you think about multiplying this over companies, server rooms, etc., it adds up fast. This works on desktops, servers, laptops, whatever.

The easiest way to save power is with CPU frequency scaling. This is a technology that lets you adjust how fast a running CPU runs, while it’s running. When CPUs run at slower speeds, they consume less power. Most CPUs are set to their maximum speed all the time, even when the system isn’t using them. Linux has support for keeping the CPU at maximum speed unless it is idle. By turning on this feature, we can save power at virtually no cost to performance. The Linux feature to handle CPU frequency scaling is called cpufreq.

Set up modules

Let’s start by checking to see whether cpufreq support is already enabled in your kernel. These commands will need to be run as root.

# cd /sys/devices/system/cpu/cpu0
# ls -l

If you see an entry called cpufreq, you are good and can skip to the governor selection below.

If not, you’ll need to load cpufreq support into your kernel. Let’s get a list of available drivers:

# ls /lib/modules/`uname -r`/kernel/arch/*/kernel/cpu/cpufreq

Now it’s guess time. It doesn’t really hurt if you guess wrong; you’ll just get a harmless error message. One hint, though: try acpi-cpufreq last; it’s the option of last resort.

On my system, I see:

acpi-cpufreq.ko     longrun.ko      powernow-k8.ko         speedstep-smi.ko
cpufreq-nforce2.ko  p4-clockmod.ko  speedstep-centrino.ko
gx-suspmod.ko       powernow-k6.ko  speedstep-ich.ko
longhaul.ko         powernow-k7.ko  speedstep-lib.ko

For each guess, you’ll run modprobe with the driver name. I have an Athlon64, which is a K8 machine, so I run:

#modprobe powernow-k8

Note that you leave off the “.ko” bit. If you don’t get any error message, it worked.

Once you find a working module, edit /etc/modules and add the module name there (again without the “.ko”) so it will be loaded for you on boot.

Governor Selection

Next, we need to load the driver that tells the kernel what governor to use. The governor is the thing that monitors the system and adjusts the speed accordingly.

I’m going to suggest the ondemand governor. This governor keeps the system’s speed at maximum unless it is pretty sure that the system is idle. So this will be the one that will let you save power with the least performance impact.

Let’s load the module now:

# modprobe cpufreq_ondemand

You should also edit /etc/modules and add a line that says simply cpufreq_ondemand to the end of the file so that the ondemand governor loads at next boot.

Turning It On

Now, back under /sys/devices/system/cpu/cpu0, you should see a cpufreq directory. cd into it.

To turn on the ondemand governor, run this:

# echo echo ondemand > scaling_governor

That’s it, your governor is enabled. You can see what it’s doing like this:

# cat cpuinfo_min_freq
800000
# cat cpuinfo_max_freq
2200000
# cat cpuinfo_cur_freq
800000

That shows that my CPU can go as low as 800MHz, as high as 2.2GHz, and that at the present moment, it’s running at 800MHz presently.

Now, check your scaling governor settings:

# cat scaling_min_freq
800000
# cat scaling_max_freq
800000

This is showing that the system is constraining the governor to only ever operate on an 800MHz to 800MHz range. That’s not what I want; I want it to scale over the entire range of the CPU. Since my cpuinfo_max_freq was 2200000, I want to write that out to scaling_max_freq as well:

echo 2200000 > scaling_max_freq

Making This The Default

The last step is to make this happen on each boot. Open up your /etc/sysfs.conf file. If you don’t have one, you will want to run a command such as apt-get install sysfsutils (or the appropriate one for your distribution).

Add a line like this:

devices/system/cpu/cpu0/cpufreq/scaling_governor = ondemand
devices/system/cpu/cpu0/cpufreq/scaling_max_freq = 2200000

Remember to replace the 2200000 with your own cpu_max_freq value.

IMPORTANT NOTE: If you have a dual-core CPU, or more than one CPU, you’ll need to add a line for each CPU. For instance:

devices/system/cpu/cpu1/cpufreq/scaling_governor = ondemand
devices/system/cpu/cpu1/cpufreq/scaling_max_freq = 2200000

You can see what all CPU devices you have with ls /sys/devices/system/cpu.

Now, save this file, and you’ll have CPU frequency scaling saving you money, and helping the environment, every time you boot. And with the ondemand governor, chances are you’ll never notice any performance loss.

This article showed you how to save power using CPU frequency scaling on Linux. I have no idea if it’s possible to do the same on Windows, Mac, or the various BSDs, but it would be great if someone would leave comments with links to resources for doing that if so.

Updated: added scaling_max_freq info

The Climate Crisis

Wow.

We just watched An Inconvenient Truth. Not much in there was new to me, but to see it all presented at once is amazing.

There are vast undisputed scientific facts out there — for instance, that CO2 content in the atmosphere is higher than it’s been ever — and we can go back 650,000 years. The linkage between that and temperatures is inescapable.

Gore makes a good point: shouldn’t we be worried about more than terrorism?

Does the thought of parts of Manhattan, San Francisco, and large parts of Florida going underwater suggest a problem exists?

This really is critical and urgent.

We’ve already been thinking about it lately as we renovate our house. We’re paying a little more now for things like airtight insulation, low-energy lighting, efficient heating. Not only will it save us money in the long run, it will help improve our lives and Jacob’s life down the road.

The movie’s website is over at climatecrisis.net.

Insurance

I was visiting with our homeowners insurance company the other day (very good folks). Because we weren’t living in our house during renovation, we had to get a more expensive type of policy. The agent that sold it do is is no longer with the company, so the new person handling our account asked me, “Why did he want you to get this policy?”

“Well, he said it was because we weren’t living there.” Then I suddenly remembered the rest of what he said, and couldn’t help cracking up. “Plus, he said that if something like a fire happened, people might not notice.”

What can I say. Psychic insurance salesman.

On that note, I was having a discussion with someone about large windows on a house. That person was saying that “everyone” always puts their large windows on the front (or back of their house, I forget which) so that potential burglers are easier to spot. He was concerned about where we were putting windows on our house.

This had never occured to me.

But I pointed out that our yard was on fire and nobody noticed for hours. What difference would it make where our windows are?

“Ah, good point,” he said.

On that note, you ought to check out rush hour in the country. Truly this is a lot of traffic for roads around here.