8 posts with tag “Linux”

Understanding GNU Screen’s hardstatus strings

My current development setup revolves mainly around Vim and GNU Screen. I use Screen only to keep sessions running between work days or in case I get disconnected, but lately I’ve been tempted to try using different windows inside Screen. In order to make this easier, I wanted one of those status lines that shows you all your windows as “tabs”.

Configuring this status line (the “hardware status line” or, as I’ll call it, “hardstatus”) is done with a single, often long string of characters in ~/.screenrc that at first can look entirely baffling:

hardstatus string "%{= KW} %H [%`] %{= Kw}|%{-} %-Lw%{= bW}%n%f %t%{-}%+Lw %=%C%a %Y-%M-%d"

Exactly.

To my dismay, almost everything I can find about hardstatus through Google are just dumps of other people’s strings, with little to no explanation about why they do what they do – it’s easy to imagine that the people who post them hardly know why they do what they do, either. GNU’s official documentation isn’t terribly helpful.

After finally deciphering a lot of what goes on in these strings, I wanted to spell it out to anybody else who might be hunting around for half a clue about this voodoo. There are (more than?) a few things I haven’t covered here, of course – truncation and conditionals, namely – but this should be enough to get you started.

Continue reading

18 Responses

Bug reporting sucks, and how to fix it: Part 2

Bug reporting sucks, it’s clear. How can it be better?

One idea that could alleviate a lot of the headaches of bug reporting while providing increased functionality is a desktop bug-reporting application. I won’t pretend to be familiar with any APIs that are made available by Launchpad, GNOME, Bugzilla, Trac, etc., but I have to imagine that some exist. I also won’t pretend that I’m the first to have this idea — it’s entirely possible that it’s been attempted and that those attempts have failed many times. But from where I’m sitting it seems like a near-perfect solution. Here are the benefits we’d get from a desktop bug-reporting application:

  1. It can manage your bug tracker logins.
    Imagine having all your bug tracker logins stored in a little database for you on your desktop. More than that, imagine being able to register at a new bug tracker with just a few clicks using the personal information kept by the application. 
  2. It can identify the bug tracker used by a given application.
    This may actually be a bit difficult. It’s possible that this could be done by having applications make this info available in some way, although that puts a burden on application developers, and I assume there is no system currently in place for something like this. It’d require some creativity. 
  3. It can identify the package in the appropriate bug tracker against which to file a bug.
    Launchpad is probably the bug tracker with which I’m most familiar, and there in particular it seems to me to be plausible for a bug-reporting application to easily find the package against which a bug should be filed. How many people even know that Ubuntu’s default PDF viewer is called “Evince,” or that its default image viewer is called “Eye of GNOME,” or especially that the Eye of GNOME package is called “eog”? Imagine instead being able to choose from a list of running applications and having the bug-reporting application do the rest. 
  4. It can provide better search for duplicates.
    Launchpad only presents you with possible duplicates after you’ve entered the title of your bug report. A desktop application, on the other hand, could continue to search for duplicates as you’re elaborating on the bug in your description, updating on-the-fly and presenting you with relevant excerpts from the potential duplicates’ descriptions. And if it has a high enough confidence in a match, it can ask “Are you sure?” before allowing you to submit. 
  5. It can collect and upload system logs.
    Not only could a desktop application attach basic system logs and hardware info, but it could catalog which version(s) of your application’s depencenc(y/ies) you have installed, potentially saving hours of work per bug. 
  6. It can open an impromptu chat with others suffering from the bug, or with package maintainers.
    By checking the online availability of other bug sufferers or package maintainers, this application could integrate with Empathy, Pidgin, or IRC to put you in contact with them, if they choose to make themselves available. 
  7. It can search existing help avenues for potential solutions to your problem.
    Stack Exchange (Ask Ubuntu, Super User), Quora, Ubuntu Forums — searching all of these places takes time, and might not even occur to a large number of users. Searching these places on-the-fly as bugs are being described might prevent unnecessary bugs from being filed in the first place, or direct bug sufferers toward temporary workarounds. 
  8. It can look for PPAs that contain updated packages that might fix the bug you’re reporting.
    Many times the applications in official repositories are outdated, and many times the most common bugs have been fixed in more recent releases. Given adequate safeguards, this could be invaluable for people desperate for a solution. 
  9. It could integrate with the messaging menu.
    “Someone just marked one of your bookmarked bugs as ‘Affects me too.’ They are available for chat. Would you like to contact them?”
    “The bug ‘[bug description here]’ has a new comment.” 

I’m sure with my limited imagination I’ve not even scratched the surface of what a desktop bug-reporting application is capable of. What else would you like to see in one? What would some of the pitfalls be? Is this practical or impractical, and why?

7 Responses

Bug reporting sucks, and how to fix it

Bug reporting sucks. Every time I’m forced to do it, it’s laborious and soul-draining. It makes me give up hope for free software having a viable future. But it’s necessary, (a) as the way I “pay” for free software, and (b) to see if maybe I can slightly hasten a hypothetical future where the software I rely on daily might work reasonably well (it’s coming!!).

Here are the stages of bug reporting, and why each of them sucks:

  1. Tolerating the flaws in the software because it’s better than filing bugs about them (time frame: 2 weeks to a lifetime)
    This stage is probably the worst, in the most insidious way, because although it is less tedious and frustrating than the following stages, it’s the one that inspires the most hopelessness in you. Unless you are completely enshrouded in ideology, you will begin to resent your computer more than Windows users do. 
  2. Figuring out against which package to file a bug (1 minute to 2 hours)
    We’re only in the second stage, and already you have to have a pretty deep familiarity with Linux and bug reporting in general to move forward. Say, for instance, that Flash is crashing Firefox. Holy hell do you have a lot of work to do! There are probably at least ten independent variables at play here, including the obvious culprits Firefox and Flash, but also your video card drivers, your Firefox plugins, and your window manager. If you don’t spend enough time experimenting with different combinations of these variables (remembering that this bug almost certainly isn’t reproducible on command), then you’ll be wasting everybody’s time by filing against the wrong package. 
  3. Figuring out where the culprit package tracks its bugs (2 to 10 minutes)
    Ooh, this is fun. First go to Launchpad, naturally. You might encounter several pages that look suspiciously similar; if that happens, just close your eyes and pick one. If your package isn’t on Launchpad, you might get lucky and find a link to some Bugzilla site or the project’s home page (“I hope the devs still own that domain!”), otherwise you are at the mercy of Google. 
  4. Remembering your password/creating an account at the correct bug tracker (1 second to 10 minutes)
    Oh right, there is no universal login for *all* Bugzilla sites, of course, so I’m going to have to create a new account. Oh, it says there already is an account associated with my email address. Huh. Ok, send me the link to create a new password. Did that go into my spam folder? Oh, ok, finally, here it is. Alright, click. Now to file a new bug. Oh wait, I’m not logged in? I thought that would have done it. Ok, “Log In.” Ok. 
  5. Looking for an existing report concerning your bug (0 seconds to 15 minutes)
    I have seen bugs with dozens of duplicates attached to them. Developers must love that. Launchpad does a pretty ok job here, searching for existing bugs based on the title you give. It’s not often that I see a match, and when I don’t, I’m not completely confident that there isn’t one somewhere in there. I usually resort to Google and use my own human brain to figure out other ways the symptoms of the bug might have been worded. I don’t want to be one of those dunces who files duplicates, after all. 
  6. Verbally articulating the symptoms of your bug in a way that is succinct, unambiguous, and thorough (2 readings of Strunk & White)
    Ok, I hope you’ve got a liberal arts degree. Oh wait, you don’t, because you are using Linux. Hell, even if you do, sometimes the subtle conditions that lead to the exposure of a bug are so difficult to describe that you end up with bloated sentences in which you’re mostly trying to convey something visual or with a far too complex linguistic parse tree:

    “So, then if I click on the button again, this time *after* clearing the .config directory, but without having restarted the program, the drop-down list (usually just the “Profiles” one, but sometimes all of them) will lose any entries that I created (except for the ones made before I upgraded to 0.0.2.11).”

    What you find yourself wanting to do is take a video of the problem occurring, but that would require subjecting yourself to the hell that is desktop video recording software for Linux, a path that will only leave you spiraling further and inescapably down into the toilet that is the bug reporting process. 

  7. You’re done! Oh oops, you’re not. Collect system logs and info (2 minutes to 30 minutes)
    One of my least favorite memories in life is the hours I spent diagnosing a problem with hibernation on my laptop. Or was it hibernation and sleep? Who the hell knows, the shit didn’t work and I banged my head against a brick wall of diagnostics and bug reporting and researching so furiously that by the end of it my roommate found me naked on the cold tile floor of our bathroom, shivering and blanketed in sweat. Oh, did the bug ever get fixed? Is there a difference between a bug getting fixed and your brain coping with the stress of it by making you numb to it? I don’t know. I don’t know. Oh anyway, yeah, be sure to grab some logs and shit, they’ll probably need that. 

That’s it. Oh my god I hate it every time, it’s like pulling god damn teeth, and it’s a wonder anybody chooses to do this with their free time. What in the hell is wrong with me? And more importantly, how can we make this better? I have an idea, but I’m too emotionally exhausted right now to get into it.

Update: Part 2

3 Responses

Flash vulnerability; upgrade to 10.1 RC in Ubuntu

Adobe has announced a potential security risk in versions of Flash earlier than 10.0.45.2. This includes the versions in Lucid’s default repositories.

If you’re feeling paranoid or would just like to try the latest Flash 10.1 release candidate, you can download it from Adobe, and follow the install instructions from Web Upd8.

Update: The final 10.1 release from Adobe has hit the main Ubuntu repositories. A software update should do it.

Leave a Comment

Karmic is still just “Linux for human beings.”

Man I wrote this a long time ago. Resigning now to the fact that I won’t finish it.

Even a couple years ago, video editing wasn’t considered an essential part of a desktop, for most users. It was the realm of professionals and hobbyists who could afford the necessary hardware to transcode video in less than an hour.

But after the advent of YouTube, adequate processors, and ubiquitous cameras — in phones, monitors, and now on the iPod nano — everybody feels that it’s their right to add scrolling text and wipes to their little movies. And rightly so; video editing software has long been expensive and difficult for a reason. But it’s almost 2010, and that shouldn’t be the case anymore. It’s no longer too much to expect to be able to put a title and a fade-out on a video where you complain about your hair, even if it is a trivial indulgence. You don’t need to know HTML to run a blog; why should you need to learn scripting languages and FFmpeg switches to run a vlog?

Steve Jobs was famously mistaken in thinking that the next step for personal computing at the turn of the century was video editing, until it took a backseat while Napster made digital music and the iPod the most prominent technologies of this decade. And as all that went on, processors got outrageously fast, and hard drives got outrageously large, even in “low-end” systems. iMovie existed, but has only recently become familiar and comfortable to large numbers of people. Microsoft’s answer to iMovie, “Microsoft Windows Video Editor 1.3” or whatever it must have been called, was feeble, buggy, and went unused as most PC owners had to work hard to derive anything of value from it; iMovie, meanwhile, practically asked Mac owners to use it. It’s my understanding that Microsoft’s video editor has improved lately, but I don’t know for sure.

Anyway, so here we are, with video editing taken for granted by some, and indignantly demanded by others. And, while we’re at it, a relatively large migration toward Ubuntu. 8.10 Intrepid was a landmark release, 9.04 followed suit, and 9.10 is becoming unequivocally the most anticipated Linux distribution by the general populace ever. Even in its beta form it’s being called “almost perfect,” and generally heralded everywhere not only as a triumph of open-source, but as a triumph of operating systems period.

There’s more to life than hard, sterile pragmatism, and if you think otherwise, you are cold and dead and nobody will ever love you.

So!, with all these people working to make Linux accessible, surely they’ve got some decent video editor up their sleeves? Well — as is a typical answer from most Linux users — yes and no. There is Cinelerra, which is very powerful and enjoys a wide user base, but even its manual admits to its Linux heritage, that “Cinelerra is not intended for consumers.” I can attest to this. In addition to Cinelerra I’ve downloaded just about every video editor there is for Linux, from Avidemux to Kdenlive to Kino to PiTiVi. All of them either crash in Ubuntu, are terrifically complicated, or lamentably simple. Simply put, there is no “iMovie for Linux.”

But this is precisely what Mark Shuttleworth is shooting for with Ubuntu. Or, rather, it’s a good metaphor for what he’s shooting for — to make Linux not merely easier to use than other distros, but to be inviting to people who don’t even know what Linux is. This is why Ubuntu’s slogan — “Linux for human beings” — has become so obsolete. Of the things that Linux provided when the Ubuntu project began in 2004, Ubuntu now provides them in a more accessible way than they’ve ever been provided, and if a person has heard of only one Linux distro, it is likely to be Ubuntu.

Now, however, with Shuttleworth explicitly taking aim at Apple, Ubuntu’s slogan — not merely for marketing purposes, but for the underlying vision of the project as a whole — needs to evolve. “Linux for human beings” begins with the premise of Linux, and qualifies it with the promise of ease-of-use. In order to gain the significant market share that Shuttleworth wants to see, and to properly orient Ubuntu’s developers toward that end, the “Linux” part of Ubuntu needs to be secondary. What must instead be emphasized is that it is a powerful, easy, fun, and free operating system that happens to use a Linux kernel.

These things are becoming increasingly true, but, as much as I am impressed by it, I can’t in good conscience say that Karmic fulfills the ultimately desired promise of Ubuntu. Karmic is still just “Linux for human beings.”

At the same time, never before has this promise been more clearly within view. Several huge — huge — things have happened recently, or are happening, to take Ubuntu beyond its current status as merely the best Linux distro, from an eccentric “third-party candidate” to a genuine competitor. Aside from its hugely increased hardware support out-of-the-box (which, bravo), I’m tempted to argue that the improved font rendering in Jaunty is the single most important step in increasing Ubuntu’s appeal — and further that anybody who disagrees with me is hopelessly out of touch with the real world.

Linux users pride themselves on withstanding the most brutal of computing environments, but it’s that kind of egotism that, if unchecked, will prevent Linux from ever gaining on the desktop. If you think pretty wallpapers are a frivolous waste of your disk space, that’s your prerogative — but if you think that it was a bad decision for Canonical to include them in Karmic, given all that they’re trying to accomplish, then you’re not paying attention. There’s more to life than hard, sterile pragmatism, and if you think otherwise, you are cold and dead and nobody will ever love you.

Leave a Comment

Ubuntu, Font Hinting, & You: A Cautionary Tale

This post was written regarding Ubuntu 8.10, Intrepid Ibex.

This isn’t the first time I’ve encountered hinting; I’ve seen it before in GIMP, even when I was using it in Windows, this font rendering option that was inexplicably on by default, and resulted in horrible kerning and misshapen letterforms. I don’t claim to know a lot about the technicalities of hinting, but everything I do understand about it agrees that it is meant to improve the shapes of letters. If this is the case, somebody is doing something very, very wrong. I haven’t seen a hinted font that looked anything other than sickly and disheveled.

I’ve complained before about the typography in Ubuntu, but my contention then was with the fonts that were in use by default, not with the way they were rendered. What I didn’t realize at the time is that the rendering is the bulk of the problem.

applicationsmenuI found this image on the Ubuntu site, and I am still in disbelief that they choose to represent themselves with font rendering like this. Look at that capital ‘A’ and ‘V’; look at the way that lower-case ‘l’ towers over its neighbors, nothing more than a single-pixel-width vertical line; look at the kerning in the ‘Rem’ of ‘Remove’ – it’s no wonder Ubuntu has about a 2% worldwide market share. They expect people to want to look at that every day of their lives? I know these are relatively subtle details, but their effects are subliminal and, I believe, psychologically hazardous.

~/.fonts.conf

Of course, when it comes to Linux, for every problem there are a few dozen solutions – or one very, very complicated solution. GNOME, the default desktop for Ubuntu, arrives with a “Font Rendering Details” dialog box in its appearance settings, to placate the mouth-breathing philistines who need a GUI to get things done. And it doesn’t really help much. I knew I’d have to get my hands dirty in ~/.fonts.conf, this XML file that is capable (and only capable) of incredibly fine-tuned font tweaking.

[Fonts are] the #1 reason why Linux hasn’t seen any significant adoption on the desktop/laptop yet. Robert Scoble

The trouble, as is the case with most Google results you get when looking for help with Linux, is that there is a glut of quick fixes, blocks of code directed towards one specific person and their specific system, that they are then told to paste into a file or save into a directory, with little to no explanation about why this solution is going to work. Or there’s the technical documentation that isn’t geared towards users. There’s no middle ground (unless you count the occasional, skeletal wiki that hasn’t been updated since 2004).

Only after looking at countless ~/.fonts.conf examples was I able to glean what was going on inside them. The full power of this file allows you to target with amazing precision any variant or size of any font your system might display and give it its own unique properties; but there are really only three(ish) of these properties that you need to know about, and I am going to explain them here.

antialias

Anti-aliasing is the trick that makes your pixels not look like pixels. You’ve noticed this when you’ve seen poorly resized images with jagged edges – they’re not properly anti-aliased. Similarly, if fonts are not anti-aliased, they look like black Tetris pieces on a white background. Anti-aliasing is going on all the time without you knowing about it, and you’d really have to make an effort not to have it, but it’s worth putting in your ~/.fonts.conf file for good measure. You’ll want to apply it to all fonts on your system, so the syntax would be:

<match target="font">
 <edit name="antialias" mode="assign">
  <bool>true</bool>
 </edit>
</match>

You can probably figure out what these things mean, but I will link to a complete manual for ~/.fonts.conf syntax at the end of this post.

rgba

This one is a matter of personal preference, I guess. I don’t see how anybody of sound mind could stand to have pink, beige, and turquoise pixels sprinkled around the edges of their letters – the result of “sub-pixel rendering” – but I guess the argument is that it allows them to be sharper. Whatever.

Trust me when I say that things look best if you tell ~/.fonts.conf to disable sub-pixel rendering, which is done like so:

<match target="font">
 <edit name="rgba" mode="assign">
  <const>none</const>
 </edit>
</match>

If you happen to be schizophrenic, or colorblind or whatever, then yes, fine, you can turn on sub-pixel rendering by changing none to rgb, to reflect the composition of your monitor’s subpixels (which are almost certainly in the order Red-Green-Blue, from left to right). Have fun scratching your eyeballs out.

rgba=rgb

rgba=rgb

rgba=none

rgba=none

Admittedly it would be nice if there were some antialiasstyle property you could set to antialiasslight or something, to lighten up those gray pixels a little bit.

hinting / autohint / hintstyle

Put it on my tombstone: Turn Off Hinting. I’m begging you. If somebody tries to tell you that this is a matter of preference, they are lying to you, and are not your friend, and are probably banging your girlfriend. If you leave hinting on, Georgia will not look like Georgia, Lucida will not look like Lucida, and Nimbus will not look like Helvetica.

hintstyle=hintnone

hintstyle=hintnone

hinting=true, autohint=true

hinting=true, autohint=true

Here is how you Turn Off Hinting®:

<match target="font">
 <edit name="hinting" mode="assign">
  <bool>false</bool>
 </edit>
 <edit name="autohint" mode="assign">
  <bool>false</bool>
 </edit>
 <edit name="hintstyle" mode="assign">
  <const>hintnone</const>
 </edit>
</match>

Alternatively, if you positively demand more “crispness” from your fonts, even at the expense of aesthetics, you might want to give slight hinting a try. From the above code, change hinting and autohint to true, and hintstyle to hintslight:

hintstyle=hintslight

hintstyle=hintslight

That’s it, roughly speaking. It’s my understanding that some specific fonts do look better if specifically targeted and adjusted with maybe slight hinting. But that’s for another day. If you do as I’ve instructed, things will be so much better for you. Leave a comment if you want my PayPal address.

This post would not have been possible without the help of these sites:

  • ArchWiki: I know nothing about Arch Linux, but this wiki page has a lot of good info.
  • fontconfig.org: the most complete and recent ~/.fonts.conf reference I’ve found.
  • Ubuntu Wiki: contains an example of a very comprehensive (if dated) ~/.fonts.conf file. Study it and learn how to do other stuff.
  • The Masterplan: another sample ~/.fonts.conf file, and the only other one that I know of that turns off hinting and subpixel rendering.

34 Responses

How to Change the Clock Theme in GNOME Do

gnome-do-clockAs far as I can tell, there are no additional “themes” out there. But I did find the SVG files the clock uses in

/usr/share/gnome-do/ClockTheme

It would be easy enough to replace these; ideally I guess there would be a section in the GNOME Do wiki to upload clock theme packages. The hands of the clock are another matter, generated by Do itself. As it is, I’ve never created an SVG in my life, so I’m stuck with a numberless clock for now.

2 Responses

Typography in Ubuntu 8.10 Intrepid Ibex

One thing I’ll never understand is why Ubuntu ships with such hideous default system fonts, when there are some perfectly great open source fonts built right into it. For instance, UnDotum is a near-exact clone of Franklin Gothic, although strangely a Google search for undotum “franklin gothic” only turns up one page that mentions the two together. It seems to be an arbitrary similarity, as the purpose of UnDotum and other UnFonts is to provide Korean characters. Anyway, it makes a good window title font.

Then there’s Nimbus Sans, which is indistinguishable from Helvetica; DejaVu Sans, which as far as I can tell is a descendant of Frutiger (and, hence, a cousin of [Apple’s] Myriad and [Microsoft’s] Segoe UI), and makes a nice all-around system font; and Libertine, which makes for a great general-purpose body serif. Once you set these as the fonts in GNOME and in Firefox, everything looks scores better — better than Ubuntu’s default look, certainly, and arguably better than Windows.

2 Responses