Part 2 of my 3-parter on configuring Ubuntu's new grub2 boot menu covers cleaning up all the bogus menu entries (if you have a multiple-boot system) and some tricks on setting color and image backgrounds:
Cleaning up your boot menu (Grub2 part 2).
I'm finally getting caught up after SCALE 8x, this year's Southern CA Linux Expo.
A few highlights (not even close to a comprehensive list):
The UbuCon and Women in Open Source (WIOS) were both great successes, with a great speaker list and good attendance. It was hard to choose between them.
Malakai Wade, Mirano Cafiero, and Saskia Wade, two 12-year-olds and an 8-year-old, presenting on "Ultimate Randomness - Girl voices in open source". Great stuff! They sang, they discussed their favorite apps, they showed an animated video made with open source tools of dolls in a dollhouse. Lots of energy, confidence and fun. Loved it! I hope to see more of these girls.
I liked Nathan Haines demo of "Quickly", an app for rapid development of python-gtk apps. It looks like a great app, especially for beginning programmers, though his demo did also illustrate the problems with complex UIs filled with a zillion similar toolbuttons. (I'm not criticising Nathan; I find UIs like that very difficult to use, especially under pressure like a live demo in front of an audience.)
Happily, the UbuCon and WIOS scheduled their lightning talks at different times (though UbuCon's conflicted with WIOS's "How to give a Lightning Talk" session). So lightning talk junkies enjoyed two hours of talks back to back, plus the chance to give two different talks to different audiences. Hectic but a lot of fun.
I was a little disappointed with the Git Tips & Tricks panel; I wanted more git tips and less discussion of projects that happen to use Git. I liked Don Marti's section on IkiWiki; it looks like a great tool and I wish Don had had more time to present.
I liked Emma Jane Hogbin's useful and interesting talk on "Looking Beautiful in Print", full of practical tips for how to design good flyers and brochures using tools like OpenOffice.
Diana Chen, who got introduced to open source only a year ago at SCALE 7x, gets the award for courage: she gave a talk on "Learning python for non-programmers" using a borrowed laptop that I'm not sure she'd even seen before the presentation. Unfortunately, the laptop turned out to be poorly suited to the task (no Python installed? Dvorak keymap?) so Diana struggled to show what she'd planned, but she came through and her demos eventually worked great. I hope she wasn't too discouraged by the difficulties, and keeps presenting -- preferably with more time to practice ahead of time. The room was absolutely packed -- they had to bring in lots more chairs and there were still a lot of people standing. There's obviously a huge amount of interest in beginner programming talks at this conference!
Shawn Powers' talk, "Linux is for Smart People, and You're Not as Dumb as You Think", was as entertaining as the title suggested -- an excellent beginner-track talk that I think everyone enjoyed.
I'm not going to review Sunday's program, because I was busy obsessing over my own "Featherweight Linux" talk. I'll just say that SCALE is a great place to give a talk -- the audience was great, with excellent questions and no heckling and, most important, they laughed when I hoped they would. :-)
I didn't get to spend much time on the show floor, but it looked active and fun.
The Linux Astronomy folks had a fantastic display, with a big table with a simulated Martian landscape and a couple of robotic rovers exploring it and a robotic telescope driven by a milling machine program, as well as computers exhibiting a selection of Linux astronomy, science and math-teaching software.
ZaReason had a booth, and my mom was able to get info on how to get a spare battery for her laptop. (Can I take a moment to say how cool it is to be wandering around a Linux conference with my mom, who's carrying her own Linux netbook?)
An Ubuntu/Canonical table was testing people's laptops for compatibility with the next Ubuntu release. (There may have been other distros tested as well; I wasn't clear on that.)
Engineers Without Borders, Orange County looked really interesting and assured me that not all of them were in Orange County, and there's activity up here in the Bay Area as well. Definitely on my list to learn more.
Linux Pro magazine was giving out copies of Linux Pro and Ubuntu User, both fantastic magazines packed with good articles.
One notable feature of SCALE is the low price. This conference is very affordable, which means there are a lot of hobbyists, beginners and even people just considering trying Linux. They've offered a "Beginner track" for several years, though not all the talks in that track are really accessible to beginners (speakers: here's your chance to propose that great beginner talk the other conferences aren't interested in! Help some new folks!) There's a lot of energy and diversity and a wide range of interests and knowledge -- yet there's still plenty of depth for hardcore Linux geeks.
Overall, a fantastic conference. The SCALE organizers do a great job of organizing everything, and if there were any glitches they weren't evident from the outside.
I gave a lightning talk at the Ubucon -- the Ubuntu miniconf -- at the SCALE 8x, Southern California Linux Expo yesterday. I've been writing about grub2 for Linux Planet but it left me with some, well, opinions that I wanted to share.
A lightning talk is an informal very short talk, anywhere from 2 to 5 minutes. Typically a conference will have a session of lightning talks, where anyone can get up to plug a project, tell a story or flame about an annoyance. Anything goes. I'm a lightning talk junkie -- I love giving them, and I love hearing what everyone else has to say.
I had some simple slides for this particular talk. Generally I've used bold or other set-offs to indicate terms I showed on a slide.
SCALE 8x, by the way, is awesome so far, and I'm looking forward to the next two days.
What's a grub? A soft wriggly worm.
But it's also the Ubuntu Bootloader. And in Karmic, we have a brand new grub: grub2!
Well, sort of. Karmic uses Grub 2 version 1.97 beta4. Aside from the fact that it's a beta -- nuff said about that -- what's this business of grub TWO being version ONE point something? Are you hearing alarm bells go off yet?
But it must be better, right? Like, they say it cleans up partition numbering.
Yay! So that confusing syntax in grub1, where you have to say (hd0,0) that doesn't look like anything else on Linux, and you're always wanting to put the parenthesis in the wrong place -- they finally fixed that?
Well, no. Now it looks like this: (hd0,1)
THEY KEPT THE CONFUSING SYNTAX BUT CHANGED THE NUMBER!
Gee, guys, thanks for making things simpler!
![[boring ubuntu boot screen]](http://shallowsky.com/blog/images/screenshots/justblackscreen.jpg)
But at least grub2 is better at graphics, right? Like what if you want to add a background image under that boring boot screen? A dark image, because the text is white.
Except now Ubuntu changes the text color to black. So you look in the config file to find out why ...
if background_image `make_system_path_relative... set color_normal=black/black
... there it is! But why are there two blacks? Of course, there's no documentation. They can't be fg/bg -- black on black wouldn't make any sense, right?
Well, it turns out it DOES mean foreground and background -- but the second "black" doesn't mean black. It's a special grub2 code for "transparent". That's right, they wrote this brand new program from scratch, but they couldn't make a parser that understands "none" or "transparent".
What if you actually want text with a black background? I have no idea. I guess you're out of luck.
Okay, what about dual booting? grub's great at that, right? I have three distros installed on this laptop. There's a shared /boot partition. When I change something, all I have to do is edit a file in /boot/grub. It's great -- so much better than lilo! Anybody remember what a pain lilo was?
# # DO NOT EDIT THIS FILE # # It is automatically generated by /usr/sbin/grub-mkconfig using templates # from /etc/grub.d and settings from /etc/default/grub #
Oops, wait -- not with grub2. Now I'm not supposed to edit that file. Instead, I edit files in TWO places, /etc/grub.d and /etc/default/grub.conf, and then run a program in a third place, /usr/bin/update-grub. All this has to be done from the same machine where you installed grub2 -- if you're booted into one of your other distros, you're out of luck.
grub2 takes us back to the bad old days of lilo.
FAIL
Grub2 really is a soft slimy worm after all.
But I have some ideas for workarounds. If you care, watch my next few articles on LinuxPlanet.com.
Update: links to Linux Planet articles:
Part 1: Grub2 worms into Ubuntu
Part 2: Cleaning up your boot menu
Part 3: Why use Grub2? Good question!
Unhandled exception, error code = 5395.
I tried all sorts of things in the feedme code that calls Plucker -- adding --beamable, moving it earlier or later in the argument list, trying other arguments. --beamable is supposed to affect the "copy protect bit", but checking on the Palm devices confirmed the copy protect bit wasn't set, and still beaming didn't work.
And I just stumbled on the answer tonight, and since it's not documented anywhere, I must document it in case somewhere, there's someone else who still uses PalmOS and Plucker struggling with this problem.
It turns out that a document with a colon in the name can't be beamed. On any PalmOS device we've tried, regardless of generation or manufacturer. This of course isn't documented anywhere I can find.
So Fri: BBC World News isn't beamable. But simply give it a colonoscopy -- rename it to Fri BBC World News -- and beaming works great.
Sheesh! Ain't debugging grand?
Upgraded to Ubuntu 9.10 Karmic and wondering how to configure your boot menu or set it up for multiple boots?
Grub2 Worms Into Ubuntu (part 1) is an introductory tutorial -- just enough to get you started. More details will follow in parts 2 and 3.
I haven't been using the spare machine much lately. So I hadn't noticed until last week that since upgrading to the emacs 23.1.1 on Ubuntu Karmic koala, every time I press the Scroll Lock key -- the key my KVM uses to switch to the other computer -- with focus in an emacs window, emacs beeps and complains that the key is unbound.
That was a problem I thought I'd solved long ago, an easy fix in .emacs:
(global-set-key [scroll-lock] 'ignore)But in emacs 23, it wasn't working any more. Emacs listed the key as "<Scroll_Lock>", but using that directly in global-set-key doesn't work.
The friendly and helpful (really!) crew at #emacs found me a solution, after some fiddling around.
(global-set-key (kbd "<Scroll_Lock>") 'ignore)
I had the opportunity to participate in a focus group on NASA's new "citizen science" project, called Moon Zoo, with a bunch of other fellow lunatics, amateur astronomers and lunar enthusiasts.
Moon Zoo sounds really interesting. Ordinary people will analyze high-resolution photos of the lunar surface: find out how many boulders and craters are there. I hope it will also include more details like crater type and size, rilles and so forth, though that wasn't mentioned. These are all tasks that are easy for a human and hard for a computer: perfect for crowdsourcing. Think Galaxy Zoo for the moon. The resulting data will be used for planning future lunar missions as well as for general lunar science.
It sounds like a great project and I'm excited about it. But I'm not going to write about Moon Zoo today -- it doesn't exist yet (current estimate is mid-March), though there is a preliminary PDF. Instead, I want to talk about some of the great ideas that came out of the focus group.
The primary question: How do we get people -- both amateur astronomers and the general public, people of all ages -- interested in contributing to a citizen science project like Moon Zoo?
Here are some of the key ideas:
This was the most important point, echoed by a lot of participants. Some people felt that many of the existing "citizen science" projects project the attitude "We want something from you, but we're not going to give you anything in return." If you use crowdsourcing to create a dataset, make it available to the crowd.
Opening the data has a lot of advantages:
Projects like Wikipedia and Open Street Map, as well as Linux and the rest of the open source movement, show how much an open data model can inspire contributions.
People cited the example of SETI@Home, where teams of contributors can compete to see who's contributed the most. Show rankings for both individuals and groups, so they can track their progress and maybe get a bit competitive with other groups. Highlight groups and individuals who contribute a lot -- maybe even make it a formal competition and offer inexpensive prizes like T-shirts or mugs.
A teenaged panel member had the great suggestion of making buttons that said "I'm a Moon Zookeeper." Little rewards like that don't cost much but can really motivate people.
They wanted to hear ideas for publicizing Moon Zoo to groups like our local astronomy clubs.
I mentioned that I've often wanted to spread the word about Galaxy Zoo, but it's entirely a web-based application and when I give talks to clubs or school groups, web access is never an option. (Ironically, the person leading the focus group had planned to demonstrate Galaxy Zoo to us but couldn't get connected to the wi-fi at the Lawrence Hall of Science.)
Projects are so much easier to evangelize if you can download an offline demo.
And not just a demo, either. There should be a way to download a real version, including a small data set. Imagine if you could grab a Moon Zoo pack and do a little classifying whenever you got a few spare minutes -- on the airplane or train, or in a hotel room while traveling.
Important note: this does not mean you should write a separate Windows app for people to download. Keep it HTML, Javascript and cross platform so everyone can run it. Then let people download a local copy of the same web app they run on your site.
Lots of people use smartphones more than they use a desktop computer these days. Make sure the app runs on all the popular smartphones. And lots of kids have access to handheld web-enabled game consoles: you can reach a whole new set of kids by supporting these platforms.
Lots of people are competitive by nature, and like to feel they're getting better at what they're doing. Play to that: let users advance as they get more experienced, and give them the option of doing harder projects. "I'm up to level 7 in Moon Zoo!"
Facebook. Twitter. Nuff said.
Quite a few scientific publications have arisen out of Galaxy Zoo -- yet although most of us were familiar with Galaxy Zoo, few of us knew that. Why so secretive? They should be trumpeting achievements like that.
How many times have you volunteered for a survey or study, then wondered for years afterward how the results came out? Researchers never contact the volunteers when the paper is finally published. It's frustrating and demotivating; it makes you not want to volunteer again. Lots of us sign up because we're curious about the science -- but that means we're also curious about the results.
With citizen science projects, this is particularly easy. Set up a mailing list or forum (or both) to discuss results and announce when papers are published. Set up a Twitter account and a Facebook group to announce new papers to anyone who wants to follow. This is the age of Web 2.0, folks -- there's no excuse for not communicating.
I don't know if NASA will listen to our ideas. But I hope they do. Moon Zoo promises to be a terrific project ... and the more of these principles they follow, the more dedicated volunteers they'll get and that will make the project even better.
I spent a morning wrestling with git after writing a minor GIMP fix that I wanted to check in. Deceptively simple ideas, like "Check the git log to see the expected format of check-in messages", turned out to be easier said than done.
Part of the problem was git's default colors: colors calculated to be invisible to anyone using a terminal with dark text on a light background. And that sent me down the perilous path of git configuration.
git-config
does have a manual page. But it lacks detail: you can't get
from there to knowing what to change so that the first line of commits
in git log doesn't show up yellow.
But that's okay, thought I: all I need to do is list the default settings, then change anything that's a light color like yellow to a darker color. Easy, right?
Well, no. It turns out there's no way to get the default settings -- because they aren't part of git's config; they're hardwired into the C code.
But you can find most of them with a seach for GIT_COLOR in the source. The most useful lines are these the ones in diff.c, builtin-branch.c and wt-status.c.
The next step is to translate those C lines to git preferences, something you can put in a .gitconfig. Here's a list of all the colors mentioned in the man page, and their default values -- I used "normal" for grep and interactive where I wasn't sure of the defaults.
[color "diff"] plain = normal meta = bold frag = cyan old = red new = green commit = yellow whitespace = normal red [color "branch"] current = green local = normal remote = red plain = normal [color "status"] header = normal added = red updated = green changed = red untracked = red nobranch = red [color "grep"] match = normal [color "interactive"] prompt = normal header = normal help = normal error = normal
The syntax and colors are fairly clearly explained in the manual: allowable colors are normal, black, red, green, yellow, blue, magenta, cyan and white. After the foreground color, you can optionally list a background color. You can also list an attribute, chosen from bold, dim, ul, blink and reverse -- only one at a time, no combining of attributes.
So if you really wanted to, you could say something like
[color "status"] header = normal blink added = magenta yellow updated = green reverse changed = red bold untracked = blue white nobranch = red white bold
What's the minimum you need to get everything readable? On the light grey background I use, I needed to change the yellow, cyan and green entries:
[color "diff"] frag = cyan new = green commit = yellow [color "branch"] current = green [color "status"] updated = green
Disclaimer: I haven't tested all these settings -- because I haven't yet figured out where all of them apply. That's another area where the manual is a bit short on detail ...
| < | February 2010 | > | ||||
| Su | Mo | Tu | We | Th | Fr | Sa |
| 1 | 2 | 3 | 4 | 5 | 6 | |
| 7 | 8 | 9 | 10 | 11 | 12 | 13 |
| 14 | 15 | 16 | 17 | 18 | 19 | 20 |
| 21 | 22 | 23 | 24 | 25 | 26 | 27 |
| 28 | ||||||
Shallow Thoughts blog
Shallow Thoughts Archives
(all entries, by category)
Entries by Tag
About:
![[RSS feed]](https://shallowsky.com/images/logos/rssicon-25x25.png){kind=small}
|
Feeds:
RSS 2.0
| Atom
|
![[Twitter]](https://shallowsky.com/images/logos/twitter-bird-white-on-blue-25x25.png){kind=small}
|
Follow @akkakk on Twitter |
|
|
Shallow Sky Home |
![[envelope]](https://shallowsky.com/images/logos/envelope-25x25.png){kind=small}
|
Contact Akkana |
Syndicated on:
• LinuxChix Live
• Ubuntu Women
• Women in Free Software
• Graphics Planet
• Ubuntu California
Powered by PyBlosxom.