Skip to content

20 posts with tag “Ubuntu”

Trash Trouble with Symbolic Links from /home to Separate Disk

I began noticing recently that sometimes when trying to send a file to the trash, I was told that it couldn’t be moved there and that I’d have to delete it entirely to get rid of it. I didn’t really think anything of this at first, until I began to suspect that it was only happening with files in my /home directory.

My /home directory is on its own partition on a standard hard disk. The rest of the file system is on another partition on an SSD. In order to fully reap the speed benefits of an SSD, I symbolically linked as many non-personal directories as I could from /home to /var/jay on the SSD. These included ~/.local, ~/.cache, ~/.gconf, ~/.mozilla, etc.

I didn’t really know much about the way Linux/GNOME handles Trash. Files deleted from a third internal hard disk or from USB sticks would be moved to /.Trash-1000 on that device, while appearing in “Trash” in Nautilus. Files from a user’s home directory, however, don’t go to /home/.Trash-1000, or even /.Trash-1000 — instead, they go to ~/.local/share/Trash. Because in my setup this directory was on the SSD rather than the hard disk with the /home partition, GNOME refused to move it there, since that would require copying from one disk to another, which GNOME’s developers (smartly, I think) believe would be alarmingly time-consuming for someone who’s just trying to delete some files — they shouldn’t expect to see a copy dialog grinding away.

In order to try to fix this, I made ~/.local/share/Trash into a symbolic link itself, back to the /home partition at ~/Trash. After this change, things were getting trashed properly — at least, I wasn’t asked to delete them entirely — but they weren’t showing up in Nautilus’s Trash view. I don’t know how Nautilus makes itself aware of all the trash folders spread across different devices, but for whatever reason it wasn’t picking up on this one, even after several reboot cycles.

Finally I gave up and moved ~/.local back onto the same partition as /home, and now everything’s back to normal. But I’d still like to know if it’s possible to keep ~/.local on a separate disk while retaining GNOME’s and Nautilus’s ordinary trash behavior.

4 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

Reliability, Trust, and User Experience

Lately, my Dell Vostro V13 has been acting up. Or, rather, Ubuntu has been acting up on it. At first I thought it was limited to hibernation: waking from hibernate often (and I mean often) failed, shutting power off to the machine sometime during boot. Then I began noticing that it had also been happening while booting back up from an ordinary shut down. Sometimes it took three or more tries to get back to the desktop in these circumstances.

I’ve explored what feel like countless possible explanations — shutting the screen before shut down/hibernate had completed, the wireless driver, the wireless being on during shut down/hibernate, the “splash,” “quiet,” and “no_console_suspend” flags in GRUB (and their 8 permutations), two shut downs/hibernates in a row (rather than alternating), the particular version of the kernel, and, finally, some unidentifiable kink in my installation that resulted in me reinstalling Maverick entirely.

Nothing seemed to alleviate the problem. Even the third or fourth boot after reinstall (the first one after updating to the newest kernel, in fact) failed in the same manner.

Continue reading

3 Responses

The New Ubuntu Maverick System Font

When Mark Shuttleworth announced the rebranding of Ubuntu, it seemed nobody noticed that he mentioned a new system font was being developed. Currently Bitstream Vera Sans is the default (if I’m not mistaken), appearing on menu bars, title bars, buttons — pretty much everywhere. I’ve always thought it has served its purpose well, and was frankly a little worried that they wouldn’t get the new system font right. Type design is extraordinarily tricky.

Now however details are starting to emerge. OMG! Ubuntu! describes how to get a bootleg copy of it. And at UDS back in May, Bruno Maag gave a session entitled “Making Beautiful Fonts” in which he elaborated on the creation of the new font. There is now video of that session, as well as the slides, which were sadly not included in the frame.

My first impression is that it feels a bit too stiff, rigid, and tech-y. Of course there’s no way to tell until you use it on your desktop. Reassuring, however, that they’re giving it proper italics.

One Response

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

Web Typography in Ubuntu: Part 1

One of the first things a careful observer will likely notice about a fresh Ubuntu install is the distinctly odd appearance of their favorite websites. The cause for this is that, although Ubuntu ships with a fair selection of fonts, they aren’t properly assigned as aliases to the proprietary fonts that most websites call for; Helvetica and Arial have a perfect cousin in FreeSans, yet are substituted with Liberation Sans by default, the latter of whose stemmed “1” and barred “J” (among other things) is a dead giveaway. Likewise, Verdana is also substituted with Liberation Sans, when DejaVu Sans is a much closer fit. Then there’s Times New Roman, Lucida Grande, Baskerville — none of which is adequately mimicked.

Several of these fonts are better served by some Ubuntu defaults, and still others — Gill Sans, Optima, Caslon, Tahoma, and more — have decent substitutes just waiting in the repositories. Typography plays a greater role in user experience than I think most people working on Ubuntu realize, and it should be a goal of 10.10 to elevate this part of the OS as much as possible. This requires just a few extra kilobytes in packages and some changes/additions to the files in /etc/fonts/conf.d/. In a subsequent post I’ll be cataloging what those changes should be.

Continue reading

6 Responses