It also checks to see if the file is kept under RCS control. If not, it offers to make it so. RCS is a system that retains a history of a file. It is the predecessor to GIT, SubVersion, CVS and such. It doesn't store the changes in a central repository; it comes from a long-gone era before servers and networks. It simply stores the changes in a subdirectory called "RCS" in the same directory as the file. (and if it can't find that directory, it puts the information in the same directory as the file: named the same as the file with ",v" at the end.)

[More about this little-known tool after the jump.]

• If you work on a team, xed's ability to lock files prevents you from stepping on each others toes.
• If you work solo, xed's file history is a great way to keep track of changes.
• If you work on a team, xed's file history is... well, a great way to add accountability to the system.

xed even notices when the last change to the file didn't happen via xed, and offers to clean up for you.

The new version adds a few features that I contributed:

• Better security and the ability to edit filenames with spaces and funny characters (spaces, quotes, etc.) thanks to changing from Perl's system(string) calls to system(list) calls.
• The ability to set the RCS changelog message via the environment variable CIMSG.
• The ability to force non-interactive mode by setting an environment varialbe (INTERACTIVE=0. In non-interactive mode xed that assumes the defaults to any questions it asks.

These new features combine to let me do something I've always wanted to do: Friction-free updates to files: no prompts, no 'are you sure?', no request for changelog statements.

There are certain files that I need to update a lot. One example is my "cribnotes.txt" file where I log little notes that I want to remember later. It is always very tempting for me to get lazy and not record these notes. The rationalization I use is generally "Oh, it's a small note no worth my bother to answer all those 'are you sure?' and other questions. I can surely remember it without writing it down." Oh, how many times I've said that and not been able to remember it later. By making the editing process "friction-free", I don't have that excuse any more.

The alias I've set up is:

bash/ksh/sh: alias note='INTERACTIVE=0 CILOG="updated" xed ~/.cribnotes.txt'

csh/tcsh: alias note '( setenv INTERACTIVE 0 ; setenv CILOG "updated" ; xed ~/.cribnotes.txt'

Now I can simply type "note", record my thought, and save the file. No excuses.

xed is a godsend. It was originally written by the awesome programmer John Linderman at Bell Labs in ksh; later ported to Perl by Cliff Miller. The project page is here: http://www.nightcoder.com/code/xed/

I recommended it in TM4SA and I still recommend it today. No Unix system is complete without it.

One of the little-known gems at OLF is their training sessions called "OLF University." It is excellent training that is at a very nice price. Considering the high-caliber trainers that they've recruited, I think (and I've told OLFU coordinators) that training like this should be priced 2x or 3x higher. The productivity boost from just one class will pay for itself in a month or two. I recommend people sign up before the organizers start listening to me.

Beth Lynn Eicher wrote a great article about OLF and the training. Check it out.

If you aren't going to OLF University, but are going to OLF, be sure to stop by the LOPSA table!

I'll announce the topic soon :-)

Often the non-technical push-back is against the entire concept of ticket systems and nothing will be "good enough". In that case, don't bring a knife to a gun fight. In fact, find a way to avoid the fight entirely.

The Art of War and other strategy books would suggest alternate strategies like these:

• Privately confront the primary dissenter directly: talk privately with the person to find the reasons behind their actions and settle those issues. Enlist them as a supporter.
• Go around the dissenter entirely: set up the ticket system of your own choosing for a project they are not involved in, when it is successful it will be politically difficult not to expand its use to all projects.
• Go over the dissenter's head: get the dissenter's boss on board.
• Leverage influential people: If there is someone that the dissenter feels walks on water and can do no wrong, get an endorsement from that person.
• Act faster: install something and put it into action before they can push back.
• Act slower: are there benefits to putting off the decision? For example, will the dissenter retire or change jobs soon? (You may not be allowed to know that they are on the way out. If your boss smiles knowingly when you ask, maybe they know something you don't know.)
• Produce more data: Gather data and produce charts that show undeniably you are right (don't show a single charts that disagrees; if the dissenter doesn't have the raw data, they can't make those charts).
• Produce less data: Work in secret to build the system.
• The power of crowds: Can you get a lot of other people on board such that the dissenter is outvoted?
• The Power of the Demo: Are they rejecting a system they haven't actually used? Install your preferred solution on a VM and give demos to likely supporters. (The secret to a successful demo is doing at least 5 dress rehearsals)
• Divide an conquer: Find out where the opposition isn't in agreement with each other and play one side against the other.
• Isolate dissent: Identify the dissenters and exclude them from the process (find a politically viable justification for this).
• Overload the dissenter: Give them so much other work to do that they don't have time to dissent; or put so much of the research on their shoulders that they ask to be taken out of the decision process.
• Reduce the choices: Don't show 15 different models and hope they pick the one you want. Only show options that you will accept.
• Give too many choices: Show so many potential products that they are overwhelmed; declare your expertise and recommend the one you want.
• Selective comparison: Show 1 really awful system followed by a perfect demo of your system. (In a related note: At a singles bar always stand next to an ugly person.)
• Force a "win": Get agreement to default to your solution if a decision isn't made by a certain date ("because we can't delay ProjectX"). Make sure you've given them more work than can be accomplished by that date so-as to trigger the default.
• Make the dissenter think they are making the decision: If you ask a child "what do you want for dinner?" they'll ask for ice cream. If you ask, "Should we have hamburgers or hotdogs?" they'll think they're making the decision even though you've already made it for them. (Worst of all: don't list choices one at a time, they'll keep saying "no" until you run out of choices: "Do you want hamburgers?" "no" "Do you want hotdogs?" no "Umm... well, we have ice cream" "yes!").
• Take advantage of emergencies: In an emergency the normal decision process goes away. Can you create a situation (or wait for a situation) where you can get permission to install RT or ORTS "just for this one emergency" and then take advantage of the fact that "nothing is more permanent than a temporary solution"?)
• Bullies only respect other bullies: Declare that your solution is the ONLY solution and brow-beat anyone that disagrees.
• Discredit the enemy: If the dissenter is always going to find reasons to reject something, don't try to deal with the points they bring up; discredit the dissenter's opinions. ("He isn't a real stake-holder, why should we listen to him?" "He rejects anything new, remember the time....", "He won't even be using the system, why is he causing trouble for us?")
• Running code beats vaporware: a running system beats the theory that it won't work.
• Avoid the issue: Find another project to work on that will make you a success; leave this "can't win" situation to co-workers that are suckers.

If done right, these strategies could work or could get you fired. Proceed with caution. Work with your boss, or if you boss the problem, confer with peers.

Please post comments with your suggestions and experiences. (This website now supports OpenID and other systems.)

The wrong way: I've heard a number of people say they are going to try to convert all of their desktops to IPv6. I think they are picking the wrong project. While this is a tempting project, I think it is a mistake (well-intentioned, but not a good starter project). Don't try to convert all your desktops and servers to IPv6 as your first experiment. There's rarely any immediate value to it (annoys management), it is potentially biting off more than you can chew (annoys you), and mistakes affect people that you have to see in the cafeteria every day (annoys coworkers).

Instead copy the success stories I've detailed below. Some use a "outside -> in" plan, others pick a "strategic value".

Story 1: Work from the outside -> in

The goal here is to get the path from your ISP to your load balancer to use IPv6; let the load balancer translate to IPv4 for you. The web servers themselves don't need to be upgraded; leave that for phase 2.

It is a small, bite-sized project that is achievable. It has a real tangible value that you can explain to management without being too technical: "the coming wave of IPv6-only users will have faster access to our web site. Without this, those users will have slower access to our site due to the IPv4/v6 translaters that ISPs are setting up as a bandaid.". That is an explanation that a non-technical executive will understand.

It also requires only modest changes: a few routers, some DNS records, and so on. It is also a safe place to make changes because your external web presence has a good dev -> qa -> production infrastructure that you can leverage to test things properly (it does, right?).

Technically this is what is happening:

At many companies web services are behind a load balancer or reverse proxy.

ISP -> load balancer -> web farm

If your load balancer can accept IPv6 connections but send out IPv4 connections to the web farm, you can offer IPv6 service to external users just by enabling IPv6 the first few hops into your network; the path to your load balancer. As each web server becomes IPv6-ready, the load balancer no longer needs to translate for that host. Eventually you're entire web farm is native IPv6. Doing this gives you a throttle to control the pace of change. You can make small changes; one at a time; testing along the way.

The value of doing it this way is that it gives customers IPv6 service early, and requires minimal changes on your site. We are about 280 days away from running out of IPv4 addresses. Around that time ISPs will start to offer home ISP service where IPv6 is "normal" and attempts to use IPv4 will result in packets being NATed at the carrier level. Customers in this situation will get worse performance for sites that aren't offering their services over IPv6. Speed is very important on the web. More specifically, latency is important.

[Note: Depending on where the SSL cert lives, that load balancer might need to do IPv6 all the way to the frontends. Consult your load balancer support folks.]

Sites that are offering their services over IPv6 will be faster for new customers. Most CEOs can understand simple, non-technical, value statements like, "new people coming onto the internet will have better access to our site" or "the web site will be faster for the new wave of IPv6-only users."

Of course, once you've completed that and shown that the world didn't end, developers will be more willing to test their code under IPv6. You might need to enable IPv6 to the path to the QA lab or other place. That's another bite-sized project. Another path will be requested. Then another. Then the desktop LAN that the developer use. Then it makes sense to do it everywhere. Small incremental roll-outs FTW!

During Google's IPv6 efforts we learned that this strategy works really well. Most importantly we've learned that it turned out to be pretty easy and not expensive. Is IPv6 code in routers stable? Well, we're now sending YouTube traffic over IPv6. If you know of a better load test for the IPv6 code on a router, please let me know! (Footnote: "Google: IPv6 is easy, not expensive Engineers say upgrading to next-gen Internet is inexpensive, requires small team")

Story 2: Strategy Upgrades

Some people run into their boss's office and say, "OMG we have to convert everything to IPv6". They want to convert the routers, the DNS system, the DHCP system, the applications, the clients, the desktops, the servers.

These people sound like crazy people. They sound like Chicken Little claiming that the sky is falling.

These people are thrown out of their boss's office.

Other people (we'll call these people "the successful ones") go to their boss and say, "There's one specific thing I want to do with IPv6. Here's why it will help the company."

These people sound focused and determined. They usually get funding.

Little does the boss realize that this "one specific thing" requires touching many dependencies. That includes the routers, the DNS system, the DHCP system, and so on. Yes, the same list of things that the "crazy" person was spouting off about.

The difference is that these people got permission to do it.

According to a presentation I saw them give in 2008, Comcast found their 'one thing" to be: Settop box management. Every settop box needs an IP address so they can manage it. That's more IP addresses than they could reasonably get from ARIN. So, they used IPv6. If you get internet service from Comcast, the settop box on your TV set is IPv6 even though the cable modem sitting next to it providing you internet service is IPv4. They had to get IPv6 working for anything that touches the management of their network: provisioning, testing, monitoring, billing. Wait, billing? Well, if you are touching the billing system, you are basically touching a lot of things. Ooh, shiny dependencies. (There used to be a paper about this at http://www.6journal.org/archive/00000265/01/alain-durand.pdf but the link isn't working. I found this interview with the author but not the original paper.)

Nokia found their "one thing" to be: power consumption. Power consumption, you say? Their phones waste battery power by sending out pings to "keep the NAT session alive". By switching to IPv6 they didn't need to send out pings. No NAT, no need to keep the NAT session alive. Their phones can turn off their antenna until they have data to send. That saves power. In an industry where battery life is everything, any CxO or VP can see the value. A video from Google's IPv6 summit details Nokia's success in upgrading to IPv6.

Speaking of phones, T-Mobile's next generation handset will be IPv6-only. Verizon's LTE handsets are required to do IPv6. If you have customers that access your services from their phone, you have a business case to start upgrading to IPv6 now.

In the long term we should be concerned with converting all our networks and equipment to IPv6. However the pattern we see is that successful projects have picked "one specific thing to convert", and let all the dependencies come along for the ride.

Summary:

In summary, IPv6 is real and real important. We are about a year away from running out of IPv4 addresses at which point ISPs will start offering IPv6 service with translation for access to IPv4-only web sites. Successful IPv6 deployment projects seem to be revealing two successful patterns and one unsuccessful pattern. The unsuccessful pattern is to scream that the sky is falling and ask for permission to upgrade "everything". The sucessful patterns tend to be one of:

• Find one high-value (to your CEO) reason to use IPv6: There are no simple solutions but there are simple explanations. Convert just that one thing and keep repeating the value statement that got the project approved. There will be plenty of dependencies and you will end up touching many components of your network. This will lead the way to other projects.
• Work 'from the outside -> in": A load balancer that does IPv6<->IPv4 translation will let you offer IPv6 to external customers now, gives you a "fast win" that will bolster future projects, and gives you a throttle to control the speed at which services get native support.

I'd love to hear from readers about their experiences with convincing management to approve IPv6 projects. Please post to the comments section!

-Tom

P.S. Material from the last Google IPv6 conference is here: http://sites.google.com/site/ipv6implementors/2010/agenda

The Ohio LinuxFest is proud to announce that registration is now open for Ohio LinuxFest. The schedule has also been announced, and this year will feature a fantastic line-up of talks for new and experienced Linux users. The 2010 Ohio LinuxFest takes place in Columbus, Ohio at the Greater Columbus Convention Center from September 10 through September 12, 2010.

The keynote is Christopher “Monty” Montgomery of Xiph.org will be talking about next generation open source media formats.

Admission is free but space is limited. Supporters can opt for the $65 package that includes lunch and an OLF t-shirt, or the $350 package that includes admission to the “OLF University” training program (which is so good I really think they should charge twice as much. Sign up before they start listening to crazy people like me!)

Sign up today at http://ohiolinux.org/register.html

More info at http://ohiolinux.org

Whether you want to watch a short, funny talk about Electronic Voting, the "Best Paper" presentation about a new security model for safe web browsing, or a technical and thought-provoking talk about how concurrency is changing everything we do by a computer science legend, this channel has everything a geek could want. (well, it's 8 videos so far, so maybe not everything.)

[If you don't have time for those videos, maybe the videos on www.TomOnTime.com will help you find more free time.]