Paul Tagliamonte: Linode pv-grub chaining
I've been using Linode since 2010, and many of my friends have heard me talk about how big a fan I am of linode. I've used Debian unstable on all my Linodes, since I often use them as a remote shell for general purpose Debian development. I've found my linodes to be indispensable, and I really love Linode.
Recently, because of my work on Docker, I was forced to stop using the Linode kernel in favor of the stock Debian kernel, since the stock Linode kernel has no aufs support, and the default LVM-based devicemapper backend can be quite a pain.
The btrfs errors are ones I fully expect to be gone soon, I can't wait to switch back to using it.
I tried loading in btrfs support, and using that to host the Docker instance backed with btrfs, but it was throwing errors as well. Stuck with unstable backends, I wanted to use the aufs backend, which, dispite problems in aufs internally, is quite stable with Docker (and in general).
I started to run through the Linode Library's guide on PV-Grub, but that resulted in a cryptic error with xen not understanding the compression of the kernel. I checked for recent changes to the compresson, and lo, the Debian kernel has been switched to use xz compression in sid. Awesome news, really. XZ compression is awesome, and I've been super impressed with how universally we've adopted it in Debian. Keep it up! However, it appears only a newer pv-grub than the Linode hosts have installed will fix this.
After contacting the (ever friendly) Linode support, they were unable to give me a timeline on adding xz support, which would entail upgrading pv-grub. It was quite disapointing news, to be honest. Workarounds were suggested, but I'm not quite happy with them as proper solutions.
After asking in #debian-kernel, waldi was able to give me a few pointers, and the following is very inspired by him, the only thing that changed much was config tweaking, which was easy enough. Thanks, Bastian!
I wanted to maintain a 100% stock configuration from the kernel up. When I upgraded my kernel, I wanted to just work. I didn't want to unpack and repack the kernel, and I didn't want to install software outside main on my system. It had to be 100% Debian and unmodified.
It's pretty fun to attach to the lish console and watch bootup pass through GRUB 0.9, to GRUB 2.x to Linux. Free Software, Fuck Yeah.
Left unable to run my own kernel directly in the Linode interface, the tact here was to use Linode's old pv-grub to chain-load grub-xen, which loaded a modern kernel. Turns out this works great.
Let's start by creating a config for Linode's pv-grub to read and use.
sudo mkdir -p /boot/grub/
Now, since pv-grub is legacy grub, we can write out the following config to chain-load in grub-xen (which is just Grub 2.0, as far as I can tell) to /boot/grub/menu.lst. And to think, I almost forgot all about menu.lst. Almost.
title grub-xen shim
Just like riding a bike! Now, let's install and set up grub-xen to work for us.
sudo apt-get install grub-xen
And, let's set the config for the GRUB image we'll create in the next step in the /boot/load.cf file:
Now, lastly, let's generate the /boot/xen-shim file that we need to boot to:
grub-mkimage --prefix '(xen/xvda)/boot/grub' -c /boot/load.cf -O x86_64-xen /usr/lib/grub/x86_64-xen/*.mod > /boot/xen-shim
Next, change your boot configuration to use pv-grub, and give the machine a kick. Should work great! If you run into issues, use the lish shell to debug it, and let me know what else I should include in this post!
Sebastian Kügler: Grumpy wizards
Oxygen Font Example
In Plasma, we have traditionally relied on the font settings dictated by the distribution we run on. This means that we’ll take whatever “Sans” font the distro has set up (or has left to something else), and worked with that. The results of that were sub-optimal at least, as it meant we had almost no control how things are going to look like for end users. Fonts matter a lot, since they determine how readable the UI is, but also what impression it gives. They also have effect on sizing, and even more so in Plasma Next.
Many widgets’ size in a UI depend on the font: Will this message actually fit into the allowed space for it? (And then: What about a translated version of this message?) In Plasma Next, we’re relying even more on sensible font settings and metrics in order to improve our support for HighDPI displays (displays that have more than 150 dots per inch). To achieve balance in the UI sizing, and to make sizing based on what really matters (how much content fits in there?), we’ve put a much stronger emphasis on fontsize-as-rendered-on-a-given screen. I’ve explained the basic mechanics behind that in anearlier post, so I won’t go into too much detail about that. Suffice to say that the base unit for our sizing is the height of the letter M rendered on the screen. This gives us a good base metric that takes into account the DPI of the screen, but also the preference of the font as set up by the user. In essence, this means that we design UIs to fit a certain number of columns and rows of text (approximately, and with ample dynamic spacing, so also longer translations fit well). It also means that the size of UI elements is not expressed in pixels anymore, and also not relative to the screen resolution, but that you get roughly the same physical size on different displays. This seems to work rather well, and we have gotten little complaints about sizing being off.
Relying on font metrics for low-level sizing units also means that we need the font to actually tell us the truth about its sizing. We need to know for example, how many pixels a given font on a given screen with a given pointsize will take, and we need this font to actually align with these values. This sounds quite logical, but there are fonts out there who don’t do a really good job in telling their metrics. This can lead to over- or undersizes UIs, alignment and margins being off, and a whole bunch of other visual and usability problems. It also looks bad. I find it personally quite frustrating when I see UIs that I or somebody else has spent quite some time on “getting it juuuuuust right”, and then seeing it completely misaligned and wrongly sized, just because some distro didn’t pay enough attention to choose a well-working (by our standards, of course ;)) font.
Oxygen Font in Kickoff Launcher rendered at 180DPI
So, to mitigate these cases, we’ve chosen to be a bit more bold about font selection in Plasma Next. We are now including the Oxygen font and setting it up as default on new installs. This means that we know the defaults work, and they work well across a range of displays and systems. We’re also defaulting to certain renderer settings, so the fonts look as smooth as possible on most machines. This fixes a slew of possible technical issues, but it also has a huge impact on esthetics. By setting a default font, we provide a clearer idea of “with this setup, we feel it’s going to look just right”.
For this, we’ve chosen the Oxygen font, which has been created by Vernon Adams, is released under the SIL Open Font License and has been created under the Google and a really beautifully done, modern, simple and clean typeface. It is optimized for rendering with Freetype, and it mainly targets web browsers, desktops, laptops and mobile devices. Vern has created this font for Oxygen and in collaboration with some of the Oxygen designers. The font has actually been around for a while already, but we feel it’s now ready for prime-time, so limelight it is.
As it happens with Free software, this has been a long-lasting itch to scratch for me. One of the first thing I had to do with every install of Plasma (or previously, KDE 3 even), was to change the fonts to something bearable. Imagine finishing the installer, and being greeted with Helvetica — Barf. (And Helvetica isn’t even that bad a font, I’ve seen much worse.) I’m glad we could fix this now in Plasma Next, and I’m confident that this will help many users having a nicer looking desktop without changing anything.
Apart from the technicalities, there will always be users who have a strong preference for a certain font, or setting. For those, we have the font selection in our systemsettings, so you can always set up your personally preferred font. We’re just changing the default.
Kubuntu Wire: Univention Corporate Client 2.0 – First milestone released
Univention Corporate Client is a derivative of Kubuntu for commercial customers. It comes with a bunch of advanced administrative tools to make configuration easier for say Samba.
Version 2.0 has just been released and it comes with an update to Kubuntu 14.04 LTS.
You can download an ISO to test from the UCC page.
Univention Corporant Client 1.0
Ubuntu Podcast from the UK LoCo: S07E07 – The One with the Jellyfish
Alan Pope, Mark Johnson, Tony Whitmore, and Laura Cowen are in Studio L for Season Seven, Episode Seven of the Ubuntu Podcast!
In this week’s show:-
We’ll be back next week, when we’ll interview Graham Morrison from Linux Voice and go through your feedback.
Please send your comments and suggestions to: firstname.lastname@example.org
Join us on IRC in #uupc on Freenode
Leave a voicemail via phone: +44 (0) 203 298 1600, sip: email@example.com and skype: ubuntuukpodcast
Follow us on Twitter
Find our Facebook Fan Page
Follow us on Google+
Valorie Zimmerman: Today's catch-up meeting with the Ubuntu Community Council
The Kubuntu team has been thinking about what to bring up to the CC for a few weeks, and at our Mumble meeting, discussed it there as well. Rohan Garg, Scott Kitterman, and Philip Muscovac (Shadeslayer, ScottK, and Yofel) attended with me (thank goodness!).
We put all our discussion items on a wiki page: https://wiki.kubuntu.org/Kubuntu/CCmeeting. Since the moin moin wiki is unreliable, here is our list:
Summing up -- PAST
Since last year, the threats of legal action against Mint and other derivative distributions have upset our community. We were disappointed in the reaction of the CC -- it seemed to us that the CC was just doing as Canonical directed, rather than work with Mint to bring them into the community.
We continue to feel apprehension over Wayland/Mir situation, which has brought the Ubuntu brand into controversy, and has caused a lot of bad feelings from our upstream. We hope for peace and technical excellence.
We are missing our face-to-face UDS meetings with the rest of the Ubuntu community. Last year and again this year we've arranged a Kubuntu meeting at the KDE yearly meeting, Akademy. Last year we met in Bilbao, this year it will be held in Brno, in the Czech Republic. However, we really miss being able to touch base with the rest of the Ubuntu community.
We have our own webserver now, at Kubuntu.co.uk. Kubuntu.org will be moved there soon.
We're now using the KDE wikis to develop our user docs, and some community wiki pages. Moin moin is just not reliable. We've gained some more translations this way for the documentation. We ran out of people who were experts in Docbook, which is why we started using the MM wiki. http://userbase.kde.org/Kubuntu is for writing; when docs are done they are moved to the website.
We are wondering about the state of donations. On the donations page, a report is promised, but we've not seen one, and none are linked to. http://community.ubuntu.com/help-information/funding/
Discussing how to handle KDE's new Frameworks, Plasma Next, and new Qt. In 14.10 we'll be rather conservative, and offer the newest stuff being released this summer in a PPA. We may be able to spin an ISO of this software; we are still pondering our best path forward.
It was encouraging to hear from Mark Shuttleworth during the meeting, as well as Jono on the funding report. I'm not sure any issues were resolved, but it did feel like the air was cleared.
Full text of the meeting is here: http://irclogs.ubuntu.com/2014/05/15/%23ubuntu-meeting.html#t17:39. Thanks to tsimpson for the link. :-)