pk stuff

This from Xen wiki:

These messages are from a glibc that was built with negative GS register offsets. Xen can run with negative GS register references, but it must “trap and emulate” this condition, which is relatively resource intensive, and quite slow.

If you don’t have a patched glibc, see the no-tls-direct-seg-refs patch mentioned in XenSpecificGlibc.

Most newer distributions are shipped with a “-mno-tls-direct-seg-refs” compiled glibc, but it might not be enabled by default.

Some newer distributions like the RHEL5 Beta1/Beta2 require the ld.so.conf.d trick below to refer to the patched glibc.

Some slightly older distributions like Ubuntu Dapper can be fixed with a simple rebuild of glibc: (see UbuntuDapperHowTo).

echo ‘hwcap 0 nosegneg’ > /etc/ld.so.conf.d/libc6-xen.conf && ldconfig

Reference Link: https://lists.xensource.com/archives/html/xen-users/2006-11/msg00026.html and https://www.mail-archive.com/[email protected]/msg00041.html

To ride the bleeding edge with Firefox, check out this site:
https://www.ubuntu-inside.me/2009/05/daily-firefox-35-36-repository-for.html

Summary of ubuntu-inside page: The released and nightly versions of firefox can be installed side-by-side, although only one can run at a time. The repository has 2 firefox packages: the usual branded Firefox package, called firefox-3.5 or 3.6, and the other is abrowser-3.5 or 3.6 which refers to an unbranded build of firefox. Install either one.

Be warned! This is DAILY mozila repository.

Edit sources.list to add the appropriate repository, depending on your Ubuntu release :

$sudo gedit /etc/apt/sources.list

And add one of them which matches with your Ubuntu you are using :

For Ubuntu Karmic Koala :

deb https://ppa.launchpad.net/ubuntu-mozilla-daily/ppa/ubuntu karmic main
deb-src https://ppa.launchpad.net/ubuntu-mozilla-daily/ppa/ubuntu karmic main

For Ubuntu Jaunty :

deb https://ppa.launchpad.net/ubuntu-mozilla-daily/ppa/ubuntu jaunty main
deb-src https://ppa.launchpad.net/ubuntu-mozilla-daily/ppa/ubuntu jaunty main

For Ubuntu Intrepid :

deb https://ppa.launchpad.net/ubuntu-mozilla-daily/ppa/ubuntu intrepid main
deb-src https://ppa.launchpad.net/ubuntu-mozilla-daily/ppa/ubuntu intrepid main

For Ubuntu Hardy :

deb https://ppa.launchpad.net/ubuntu-mozilla-daily/ppa/ubuntu hardy main
deb-src https://ppa.launchpad.net/ubuntu-mozilla-daily/ppa/ubuntu hardy main

While binbash at ubuntu-inside.me describes explains how to install public keys using a script here, I was able to get away with:

$ gpg --keyserver hkp://keyserver.ubuntu.com --recv-keys EF4186FE247510BE
$ gpg --export --armor EF4186FE247510BE | sudo apt-key add -

Then update your index :

$sudo apt-get update

Install Firefox 3.6 you can install 3.6 or abrowser instead of firefox, that is your choice) :

$sudo apt-get install firefox-3.6 firefox-3.6-gnome-support

To run from command line: firefox-3.6
Or from menu: Applications > Internet > Namoroka Web Browser.
To use as default firefox, create link from firefox-3.6 to firefox

Problem installing Ant under Ubuntu Karmic Koala (9.10): apt insists on installing gcj even if Sun JRE is already present.
Workaround for karmic, for those unfamiliar with apt. In the console, type:

sudo apt-get install ant ant-gcj- ant-optional-gcj- gcj-4.4-base- libgcj-common-

I was surprised to see Ruby doesn’t have this handy function:

module Enumerable
def dups
inject({}) {|h,v| h[v]=h[v].to_i+1; h}.reject{|k,v| v==1}.keys
end
end

I like JFS: better performance than ext3 and more reliable than reiserfs. However installation under CentOS is awkward, at best. Here’s one of the better install guides I found. Quoted from https://www.norlin.se/blog/2006/12/28/centos-and-jfs/

JFS (Journaled File System) is a file system from IBM. I have always really liked this file system since I first came across it, working with AIX, but I have never used it in a Linux environment until now. When you read comparisons of different file systems it seems JFS always comes out in a top position. For Linux it is sometimes beaten by XFS, but I think that is due to the fact that XFS is more widely used on Linux.

For some reason RedHat seems to have taken out support for JFS in RHES, but it is available for CentOS using the kernel in the CentosPlus repository. The process to upgrade an existing Centos installation to support JFS is simply to update the kernel with the kernel in centosplus and install jfsutils:

yum –enablerepo=centosplus install kernel-smp
yum –enablerepo=centosplus install kernel-smp-devel
yum install jfsutils

Then you probably need to change the “default” row in grub.conf and reboot to start using the new kernel with JFS support.

To create a JFS file system on a new partition use fdisk and mkfs -t jfs.

I think you need to stick to ext3 for the root and boot file systems though and there is no path (at least that I know of) for migrating an existing ext3 file system to JFS “in place”.

Quoted from Jay Fields blog:

Up until a few years ago I’d never done any type of public speaking. I’m outspoken among friends, but generally shy around strangers. However, some opportunities presented themselves and I decided to take the leap into the world of presenting. I thought it might be helpful to document some lessons I’ve learned. If you decide to take the leap into presenting, I hope these ideas make your journey a bit easier than mine.

• Get Help – I took a class at Speakeasy (NYC). The class that I took forced me to stand in front of a small group of strangers, present on any topic I liked, and have the entire thing recorded. I learned about things that I was doing wrong, but I also got to see what mistakes the other people in the class were making. It was the single largest thing that improved my public speaking.
• Practice – the last public talk I gave was at QCon SF 2008. In the weeks leading up to that talk I rehearsed the presentation at least 25 times. There’s so many reasons why a presentation can go wrong, so you’ll want to make sure you have the content down cold. You’ll lose the audience’s trust if at any time you look as though you don’t have the content down 100%.
• Don’t Script Jokes – at QCon London 2008, I was feeling nervous and chatting with Jim Webber. Jokingly, I said “maybe I’ll open with: My name is Jay Fields, and yes, I’m American, but I guess you already knew that from my weight problem”. Jim thought it was “brilliant”. So I opened with the joke. But, it didn’t come out smooth or well-timed, it came out dry and forced. No one laughed, and I got to start out my presentation with awkward silence. If you’re naturally funny, it’s fine to improv a joke in the middle of the presentation; otherwise, I suggest sticking to the content.
• Know Your Audience – Audience’s will react to your content in different ways based on several factors, it’s important to consider these factors when putting together your content. For example, a local Rails User Group may laugh at your joke about DBAs. However, at QCon there are likely to be DBAs, CTOs, and other audience members who may not find your DBA humor amusing. It’s also valuable to consider language barriers. In Europe, where my audiences often very mixed, jokes never seemed to amuse the audience in my talks or any that I attended. Maybe, the humor didn’t translate well, or maybe I was moving too quickly. Either way, I made a mental note to stick to the content when my audience was likely to speak English as a second language.
• Look Natural – At Speakeasy I learned that “arms at your sides” is how to look natural to the audience. It’s extremely uncomfortable and feels unnatural to me, but I have the recorded video to show that I’m wrong. The problem is, if you are always waiving your arms around, or hiding them behind your back, you distract the audience. That’s not to say you should never move your arms, but do it less often. I tend to point or gesture way too often, so whenever I notice that I am, I just naturally put my arms down and focus on doing that for a bit.
• Face Forward – When you turn your back on the audience, you lose them. Especially if you are talking with your back to them. Instead, take small, backward steps and always face the entire audience.
• Pictures – pictures are really the way to go. If you put text on the screen, people will read the text and tune you out. Some presenters are amazing enough that they get away with no slides at all. I don’t suggest starting there. Technical conference-goers are used to slides. However, you can stick to pictures for your slides. If you have pictures that support your ideas, you can have slides while still forcing the audience to pay attention to you for content delivery.
• Short Text – If you must use text, don’t use sentences, paragraphs, definitions, or anything else lengthy. A few words, as little as possible is the only way to go. If the audience is reading, they aren’t listening to you.
• No Bullets – If you must you text, avoid bullets. Instead, show one line at a time and hide or shade the other lines.
• Code Is Acceptable – Some ideas are more easily expressed with a snippet of code. Don’t avoid code when code is the best choice. Instead, when you bring the code up, give the audience 30 seconds (or whatever is appropriate) to digest the code, and then begin to discuss it. Just remember, as long as the code is on the screen, there will be people reading, and not paying attention to you.
• No Distractions – Distractions can ruin a presentation. Excessive transitions, morphing text, blinking text, etc all take away from the message that you are trying to express. I remember seeing a Flex presentation at RailsConf where the presenters showed their Flex Twitter Client. It was really pretty, and kept popping up tweets from conference attendees. Putting it up was awesome, leaving it up was the worst possible choice. I can’t remember anything they said after they put up the application. I tuned them out for the remainder of the talk, and read all the tweets that kept popping up. I didn’t mean to, but I was drawn to the shiny objects. After the talk I asked a few friends if the presentation was any good. They had no idea, we were all entranced by the twitter client.
• Start Small, Build Up – My wife is the first to hear (suffer) though any presentation that I put together. I practice it a few times, then present it to her, then practice a few more times, then move on to a slightly larger venue. A User Group or some peers at work are good audiences for a new talk. After you present to 10-20 people, you should feel pretty confident about giving the same presentation to 100-200 people.
• Be Original – If you use a template provided with Powerpoint or Keynote, it’s likely that someone else at the conference will be using the same template.
• Be Yourself – In my presentations I almost always swear and make some kind of sarcastic remark. That’s how I act among friends and when I act like myself in presentations people tend to accept that what I’m saying is what I believe, not what I’m trying to pitch.
• Record Coding – Don’t live code unless you’ve practiced it 100 times, know how to deal with all possible problems, and are Justin Gehtland. Okay, I’m (sort-of) kidding about having to be Justin. However, the reality is that live coding is really, really hard. Often, you can express the same thing with a recorded coding session and there’s little to no chance that things will go wrong. Justin has acting, teaching, and presentation training. He’s also ridiculously smart. Those things combined mean he can carry a live coding session even when things go very wrong. If you have the same background, go for it. Otherwise, stick with the, much more likely to succeed, recorded coding session.
• Questions – Pause for questions a few times during your presentation. It allows you to give color on ideas that you may not have clearly expressed. It also gives the audience the chance to see that you really know what you are talking about. For me, it also helps me relax and provide conversation, instead of simply lecturing.
• Breathe – You know your content, the audience doesn’t. Chances are you are going too fast. The simple rule of thumb is, the audience is always at least 5 seconds behind whatever you are saying. If you take the time to breathe or take a sip of water, you give them the opportunity to catch up.
• Relax – The best presentation ratings I’ve ever gotten were when I gave a presentation entirely hungover. I thought I was going to be terrible. But, I was too hungover to be nervous, and I gave a straightforward, natural presentation on the ideas. I’m not advocating that you get drunk the night before your presentation, but do take steps to relax, if you know how. For me, I like to have friends in the audience, a drink about an hour before the presentation and a drink right after. It’s my ritual and it helps ensure that I’m as relaxed as possible.

Almost everything I learned I got from Neal Ford, Jim Webber, and Dan North. Thanks for the ideas, gentlemen. If I left anything out, it would be cool to see additional lessons that you’ve learned throughout the years.

Update:
Steve Vinoski said…
I’d add the following:

• Always repeat any questions asked of you before answering them. This is important not only for the audience in front of you, but also especially for any audience viewing a recorded session at a later time.
• Don’t be afraid to answer “I don’t know” if someone asks you a question you don’t know. The audience would rather hear honesty than some made-up BS. Presumably you possess specialized knowledge or wisdom, otherwise you wouldn’t be up there speaking, but that doesn’t mean you know everything, and frankly the audience doesn’t expect you to.
• Ask the audience questions. This helps keep them engaged. Remember, your talk is really more about them than it is about you, so gauging the audience and adjusting accordingly can help maximize the value of your message to them.
• Should you encounter an audience member who wants to challenge you and argue with you, just politely decline to engage by saying you’ll be happy to discuss the issue with them after the talk. Back-and-forth arguments with an audience member lose and annoy most of the rest of the audience almost immediately, and since you’re probably not repeating every statement the arguer makes, anyone watching a recording of the argument hears only half of it and you lose them immediately.
• Above all, respect your audience and they’ll respect you. Except in extremely unusual circumstances, they want you to succeed because that way they’ll get the most out of your talk. If you’re a new or nervous speaker, keeping that in mind can help put you at ease.

While installing go, configuring vim syntax took longer than it should – would have been easier if I had known the following:

mkdir ~/.vim/ftdetect and ~/.vim/syntax if they don’t exist
vi ~/.vim/ftdetect/go.vim
containing:
au BufRead,BufNewFile *.go set filetype=go

copy go.vim to $GOROOT/misc/vim/go.vim to ~/.vim/syntax/

And of course, make sure you are running vim-enhanced and not vim-tiny, as tiny doesn’t support syntax highlighting.

Ever connected a hard disk to your computer without knowing how the partitions are formatted, or even what type of formatting? This surprisingly hard-to-find utility reveals all:

/usr/lib/klibc/bin/fstype /dev/sdb1

just replace sdb1 with your drive.

fstype prints something like this:

FSTYPE=jfs
FSSIZE=156225608

I have no idea why the hide this under /usr/lib/klibc/bin. Other applications in the klibc-utils package get mapped to more reasonable locations.

Here’s a useful piece from David Lee on the Rails Oceania Google Group:

If any of you are using Ubuntu this is a pretty nice way to manage multiple ruby interpreters.

It has the advantage of managing the manpages, ri, and irb as “slaves”, so they change when a new interpreter is selected.

here’s the code:

# become root
su

# make sure the packages are installed for 1.8 & 1.9 aptitude install -s  ~n^ruby1.[89]$ ~n^irb1.[89]$ ~n^ri1.[89]

# install ruby1.8 & friends with priority 500
# so this will be the default “auto” choice
update-alternatives –install /usr/bin/ruby ruby /usr/bin/ruby1.8 500
–slave   /usr/share/man/man1/ruby.1.gz ruby.1.gz
/usr/share/man/man1/ruby.1.8.gz
–slave   /usr/bin/ri ri /usr/bin/ri1.8
–slave   /usr/bin/irb irb /usr/bin/irb1.8

# install ruby1.9 & friends with priority 400
update-alternatives –install /usr/bin/ruby ruby /usr/bin/ruby1.9 400
–slave   /usr/share/man/man1/ruby.1.gz ruby.1.gz
/usr/share/man/man1/ruby.1.9.gz
–slave   /usr/bin/ri ri /usr/bin/ri1.9
–slave   /usr/bin/irb irb /usr/bin/irb1.9

# choose your interpreter
# changes symlinks for /usr/bin/ruby ,
# /usr/bin/irb, /usr/bin/ri and man (1) ruby
update-alternatives –config ruby

for those with additional interpreters in say /usr/local/bin, other Debian variants, or managing other tools, vary as required.

% man update-alternatives

hope wrapping didn’t mangle it too much, and that someone finds this useful
…

Link to original here.

Great Rails Rake tutorial from railsenvy.

More Rake stuff from railsenvy:

Now that you know enough to start writing useful rake tasks, I figured I should leave you with a few more resources. The best way to improve your programming is to read other people’s code, so a few of these are existing useful rake tasks people have written.

• These brand new rake tasks in Edge Rails create and reset your databases for you. Neato!
• Craig Ambrose wrote a Rake task to do database backups, which you can use.
• Adam Greene put together a set of Rake tasks that allow you to backup all your data to Amazon S3. He sent me an updated version of these libraries you can download here.
• Jay Fields made a good point when he talked about testing rake tasks
• Err the blog talks about a new way of setting the RAILS_ENV and teaches how to use rake to boot you into a Mysql shell (be sure to read the comments if you browse this one).
• Last, but not least, there’s the Rake Bookshelf Books and Martin Fowler’s Using the Rake Build Language tutorial . Both of these are pretty thorough, but also a little dated.

You’re all set! If you find any other good ones, feel free to post them in the comments.