Trash Trouble with Symbolic Links from /home to Separate Disk

I began notic­ing recent­ly that some­times when try­ing 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 entire­ly to get rid of it. I didn’t real­ly think any­thing of this at first, until I began to sus­pect that it was only hap­pen­ing with files in my /home direc­to­ry.

My /home direc­to­ry is on its own par­ti­tion on a stan­dard hard disk. The rest of the file sys­tem is on anoth­er par­ti­tion on an SSD. In order to ful­ly reap the speed ben­e­fits of an SSD, I sym­bol­i­cal­ly linked as many non-per­son­al direc­to­ries as I could from /home to /var/jay on the SSD. These includ­ed ~/.local, ~/.cache, ~/.gconf, ~/.mozilla, etc.

I didn’t real­ly know much about the way Linux/GNOME han­dles Trash. Files delet­ed from a third inter­nal hard disk or from USB sticks would be moved to /.Trash-1000 on that device, while appear­ing in “Trash” in Nau­tilus. Files from a user’s home direc­to­ry, how­ev­er, don’t go to /home/.Trash-1000, or even /.Trash-1000 — instead, they go to ~/.local/share/Trash. Because in my set­up this direc­to­ry was on the SSD rather than the hard disk with the /home par­ti­tion, GNOME refused to move it there, since that would require copy­ing from one disk to anoth­er, which GNOME’s devel­op­ers (smart­ly, I think) believe would be alarm­ing­ly time-con­sum­ing for some­one who’s just try­ing to delete some files — they shouldn’t expect to see a copy dia­log grind­ing away.

In order to try to fix this, I made ~/.local/share/Trash into a sym­bol­ic link itself, back to the /home par­ti­tion at ~/Trash. After this change, things were get­ting trashed prop­er­ly — at least, I wasn’t asked to delete them entire­ly — but they weren’t show­ing up in Nautilus’s Trash view. I don’t know how Nau­tilus makes itself aware of all the trash fold­ers spread across dif­fer­ent devices, but for what­ev­er rea­son it wasn’t pick­ing up on this one, even after sev­er­al reboot cycles.

Final­ly I gave up and moved ~/.local back onto the same par­ti­tion as /home, and now everything’s back to nor­mal. But I’d still like to know if it’s pos­si­ble to keep ~/.local on a sep­a­rate disk while retain­ing GNOME’s and Nautilus’s ordi­nary trash behav­ior.

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

Bug report­ing sucks, it’s clear. How can it be bet­ter?

One idea that could alle­vi­ate a lot of the headaches of bug report­ing while pro­vid­ing increased func­tion­al­i­ty is a desk­top bug-report­ing appli­ca­tion. I won’t pre­tend to be famil­iar with any APIs that are made avail­able by Launch­pad, GNOME, Bugzil­la, Trac, etc., but I have to imag­ine that some exist. I also won’t pre­tend that I’m the first to have this idea — it’s entire­ly pos­si­ble that it’s been attempt­ed and that those attempts have failed many times. But from where I’m sit­ting it seems like a near-per­fect solu­tion. Here are the ben­e­fits we’d get from a desk­top bug-report­ing appli­ca­tion:

  1. It can man­age your bug track­er logins.
    Imag­ine hav­ing all your bug track­er logins stored in a lit­tle data­base for you on your desk­top. More than that, imag­ine being able to reg­is­ter at a new bug track­er with just a few clicks using the per­son­al infor­ma­tion kept by the appli­ca­tion.
  2. It can iden­ti­fy the bug track­er used by a giv­en appli­ca­tion.
    This may actu­al­ly be a bit dif­fi­cult. It’s pos­si­ble that this could be done by hav­ing appli­ca­tions make this info avail­able in some way, although that puts a bur­den on appli­ca­tion devel­op­ers, and I assume there is no sys­tem cur­rent­ly in place for some­thing like this. It’d require some cre­ativ­i­ty.
  3. It can iden­ti­fy the pack­age in the appro­pri­ate bug track­er against which to file a bug.
    Launch­pad is prob­a­bly the bug track­er with which I’m most famil­iar, and there in par­tic­u­lar it seems to me to be plau­si­ble for a bug-report­ing appli­ca­tion to eas­i­ly find the pack­age against which a bug should be filed. How many peo­ple even know that Ubuntu’s default PDF view­er is called “Evince,” or that its default image view­er is called “Eye of GNOME,” or espe­cial­ly that the Eye of GNOME pack­age is called “eog”? Imag­ine instead being able to choose from a list of run­ning appli­ca­tions and hav­ing the bug-report­ing appli­ca­tion do the rest.
  4. It can pro­vide bet­ter search for dupli­cates.
    Launch­pad only presents you with pos­si­ble dupli­cates after you’ve entered the title of your bug report. A desk­top appli­ca­tion, on the oth­er hand, could con­tin­ue to search for dupli­cates as you’re elab­o­rat­ing on the bug in your descrip­tion, updat­ing on-the-fly and pre­sent­ing you with rel­e­vant excerpts from the poten­tial dupli­cates’ descrip­tions. And if it has a high enough con­fi­dence in a match, it can ask “Are you sure?” before allow­ing you to sub­mit.
  5. It can col­lect and upload sys­tem logs.
    Not only could a desk­top appli­ca­tion attach basic sys­tem logs and hard­ware info, but it could cat­a­log which version(s) of your application’s depencenc(y/ies) you have installed, poten­tial­ly sav­ing hours of work per bug.
  6. It can open an impromp­tu chat with oth­ers suf­fer­ing from the bug, or with pack­age main­tain­ers.
    By check­ing the online avail­abil­i­ty of oth­er bug suf­fer­ers or pack­age main­tain­ers, this appli­ca­tion could inte­grate with Empa­thy, Pid­gin, or IRC to put you in con­tact with them, if they choose to make them­selves avail­able.
  7. It can search exist­ing help avenues for poten­tial solu­tions to your prob­lem.
    Stack Exchange (Ask Ubun­tu, Super User), Quo­ra, Ubun­tu Forums — search­ing all of these places takes time, and might not even occur to a large num­ber of users. Search­ing these places on-the-fly as bugs are being described might pre­vent unnec­es­sary bugs from being filed in the first place, or direct bug suf­fer­ers toward tem­po­rary workarounds.
  8. It can look for PPAs that con­tain updat­ed pack­ages that might fix the bug you’re report­ing.
    Many times the appli­ca­tions in offi­cial repos­i­to­ries are out­dat­ed, and many times the most com­mon bugs have been fixed in more recent releas­es. Giv­en ade­quate safe­guards, this could be invalu­able for peo­ple des­per­ate for a solu­tion.
  9. It could inte­grate with the mes­sag­ing menu.
    “Some­one just marked one of your book­marked bugs as ‘Affects me too.’ They are avail­able for chat. Would you like to con­tact them?”
    “The bug ‘[bug descrip­tion here]’ has a new com­ment.”

I’m sure with my lim­it­ed imag­i­na­tion I’ve not even scratched the sur­face of what a desk­top bug-report­ing appli­ca­tion is capa­ble of. What else would you like to see in one? What would some of the pit­falls be? Is this prac­ti­cal or imprac­ti­cal, and why?

Bug reporting sucks, and how to fix it

Bug report­ing sucks. Every time I’m forced to do it, it’s labo­ri­ous and soul-drain­ing. It makes me give up hope for free soft­ware hav­ing a viable future. But it’s nec­es­sary, (a) as the way I “pay” for free soft­ware, and (b) to see if maybe I can slight­ly has­ten a hypo­thet­i­cal future where the soft­ware I rely on dai­ly might work rea­son­ably well (it’s com­ing!!).

Here are the stages of bug report­ing, and why each of them sucks:

  1. Tol­er­at­ing the flaws in the soft­ware because it’s bet­ter than fil­ing bugs about them (time frame: 2 weeks to a life­time)
    This stage is prob­a­bly the worst, in the most insid­i­ous way, because although it is less tedious and frus­trat­ing than the fol­low­ing stages, it’s the one that inspires the most hope­less­ness in you. Unless you are com­plete­ly enshroud­ed in ide­ol­o­gy, you will begin to resent your com­put­er more than Win­dows users do.
  2. Fig­ur­ing out against which pack­age to file a bug (1 minute to 2 hours)
    We’re only in the sec­ond stage, and already you have to have a pret­ty deep famil­iar­i­ty with Lin­ux and bug report­ing in gen­er­al to move for­ward. Say, for instance, that Flash is crash­ing Fire­fox. Holy hell do you have a lot of work to do! There are prob­a­bly at least ten inde­pen­dent vari­ables at play here, includ­ing the obvi­ous cul­prits Fire­fox and Flash, but also your video card dri­vers, your Fire­fox plu­g­ins, and your win­dow man­ag­er. If you don’t spend enough time exper­i­ment­ing with dif­fer­ent com­bi­na­tions of these vari­ables (remem­ber­ing that this bug almost cer­tain­ly isn’t repro­ducible on com­mand), then you’ll be wast­ing everybody’s time by fil­ing against the wrong pack­age.
  3. Fig­ur­ing out where the cul­prit pack­age tracks its bugs (2 to 10 min­utes)
    Ooh, this is fun. First go to Launch­pad, nat­u­ral­ly. You might encounter sev­er­al pages that look sus­pi­cious­ly sim­i­lar; if that hap­pens, just close your eyes and pick one. If your pack­age isn’t on Launch­pad, you might get lucky and find a link to some Bugzil­la site or the project’s home page (“I hope the devs still own that domain!”), oth­er­wise you are at the mer­cy of Google.
  4. Remem­ber­ing your password/creating an account at the cor­rect bug track­er (1 sec­ond to 10 min­utes)
    Oh right, there is no uni­ver­sal login for *all* Bugzil­la sites, of course, so I’m going to have to cre­ate a new account. Oh, it says there already is an account asso­ci­at­ed with my email address. Huh. Ok, send me the link to cre­ate a new pass­word. Did that go into my spam fold­er? Oh, ok, final­ly, 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. Look­ing for an exist­ing report con­cern­ing your bug (0 sec­onds to 15 min­utes)
    I have seen bugs with dozens of dupli­cates attached to them. Devel­op­ers must love that. Launch­pad does a pret­ty ok job here, search­ing for exist­ing bugs based on the title you give. It’s not often that I see a match, and when I don’t, I’m not com­plete­ly con­fi­dent that there isn’t one some­where in there. I usu­al­ly resort to Google and use my own human brain to fig­ure out oth­er ways the symp­toms of the bug might have been word­ed. I don’t want to be one of those dunces who files dupli­cates, after all.
  6. Ver­bal­ly artic­u­lat­ing the symp­toms of your bug in a way that is suc­cinct, unam­bigu­ous, and thor­ough (2 read­ings of Strunk & White)
    Ok, I hope you’ve got a lib­er­al arts degree. Oh wait, you don’t, because you are using Lin­ux. Hell, even if you do, some­times the sub­tle con­di­tions that lead to the expo­sure of a bug are so dif­fi­cult to describe that you end up with bloat­ed sen­tences in which you’re most­ly try­ing to con­vey some­thing visu­al or with a far too com­plex lin­guis­tic parse tree:

    “So, then if I click on the but­ton again, this time *after* clear­ing the .con­fig direc­to­ry, but with­out hav­ing restart­ed the pro­gram, the drop-down list (usu­al­ly just the “Pro­files” one, but some­times all of them) will lose any entries that I cre­at­ed (except for the ones made before I upgrad­ed to 0.0.2.11).”

    What you find your­self want­i­ng to do is take a video of the prob­lem occur­ring, but that would require sub­ject­ing your­self to the hell that is desk­top video record­ing soft­ware for Lin­ux, a path that will only leave you spi­ral­ing fur­ther and inescapably down into the toi­let that is the bug report­ing process.

  7. You’re done! Oh oops, you’re not. Col­lect sys­tem logs and info (2 min­utes to 30 min­utes)
    One of my least favorite mem­o­ries in life is the hours I spent diag­nos­ing a prob­lem with hiber­na­tion on my lap­top. Or was it hiber­na­tion and sleep? Who the hell knows, the shit didn’t work and I banged my head against a brick wall of diag­nos­tics and bug report­ing and research­ing so furi­ous­ly that by the end of it my room­mate found me naked on the cold tile floor of our bath­room, shiv­er­ing and blan­ket­ed in sweat. Oh, did the bug ever get fixed? Is there a dif­fer­ence between a bug get­ting fixed and your brain cop­ing with the stress of it by mak­ing you numb to it? I don’t know. I don’t know. Oh any­way, yeah, be sure to grab some logs and shit, they’ll prob­a­bly need that.

That’s it. Oh my god I hate it every time, it’s like pulling god damn teeth, and it’s a won­der any­body choos­es to do this with their free time. What in the hell is wrong with me? And more impor­tant­ly, how can we make this bet­ter? I have an idea, but I’m too emo­tion­al­ly exhaust­ed right now to get into it.

Update: Part 2

Reliability, Trust, and User Experience

Late­ly, my Dell Vostro V13 has been act­ing up. Or, rather, Ubun­tu has been act­ing up on it. At first I thought it was lim­it­ed to hiber­na­tion: wak­ing from hiber­nate often (and I mean often) failed, shut­ting pow­er off to the machine some­time dur­ing boot. Then I began notic­ing that it had also been hap­pen­ing while boot­ing back up from an ordi­nary shut down. Some­times it took three or more tries to get back to the desk­top in these cir­cum­stances.

I’ve explored what feel like count­less pos­si­ble expla­na­tions — shut­ting the screen before shut down/hibernate had com­plet­ed, the wire­less dri­ver, the wire­less being on dur­ing shut down/hibernate, the “splash,” “qui­et,” and “no_console_suspend” flags in GRUB (and their 8 per­mu­ta­tions), two shut downs/hibernates in a row (rather than alter­nat­ing), the par­tic­u­lar ver­sion of the ker­nel, and, final­ly, some uniden­ti­fi­able kink in my instal­la­tion that result­ed in me rein­stalling Mav­er­ick entire­ly.

Noth­ing seemed to alle­vi­ate the prob­lem. Even the third or fourth boot after rein­stall (the first one after updat­ing to the newest ker­nel, in fact) failed in the same man­ner.

Con­tin­ue →

The New Ubuntu Maverick System Font

When Mark Shut­tle­worth announced the rebrand­ing of Ubun­tu, it seemed nobody noticed that he men­tioned a new sys­tem font was being devel­oped. Cur­rent­ly Bit­stream Vera Sans is the default (if I’m not mis­tak­en), appear­ing on menu bars, title bars, but­tons — pret­ty much every­where. I’ve always thought it has served its pur­pose well, and was frankly a lit­tle wor­ried that they wouldn’t get the new sys­tem font right. Type design is extra­or­di­nar­i­ly tricky.

Now how­ev­er details are start­ing to emerge. OMG! Ubun­tu! describes how to get a boot­leg copy of it. And at UDS back in May, Bruno Maag gave a ses­sion enti­tled “Mak­ing Beau­ti­ful Fonts” in which he elab­o­rat­ed on the cre­ation of the new font. There is now video of that ses­sion, as well as the slides, which were sad­ly not includ­ed in the frame.

My first impres­sion 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 desk­top. Reas­sur­ing, how­ev­er, that they’re giv­ing it prop­er ital­ics.

Flash vulnerability; upgrade to 10.1 RC in Ubuntu

Adobe has announced a poten­tial secu­ri­ty risk in ver­sions of Flash ear­li­er than 10.0.45.2. This includes the ver­sions in Lucid’s default repos­i­to­ries.

If you’re feel­ing para­noid or would just like to try the lat­est Flash 10.1 release can­di­date, you can down­load it from Adobe, and fol­low the install instruc­tions from Web Upd8.

Update: The final 10.1 release from Adobe has hit the main Ubun­tu repos­i­to­ries. A soft­ware update should do it.

Web Typography in Ubuntu: Part 1

One of the first things a care­ful observ­er will like­ly notice about a fresh Ubun­tu install is the dis­tinct­ly odd appear­ance of their favorite web­sites. The cause for this is that, although Ubun­tu ships with a fair selec­tion of fonts, they aren’t prop­er­ly assigned as alias­es to the pro­pri­etary fonts that most web­sites call for; Hel­veti­ca and Ari­al have a per­fect cousin in FreeSans, yet are sub­sti­tut­ed with Lib­er­a­tion Sans by default, the lat­ter of whose stemmed “1” and barred “J” (among oth­er things) is a dead give­away. Like­wise, Ver­dana is also sub­sti­tut­ed with Lib­er­a­tion Sans, when DejaVu Sans is a much clos­er fit. Then there’s Times New Roman, Luci­da Grande, Baskerville — none of which is ade­quate­ly mim­ic­ked.

Sev­er­al of these fonts are bet­ter served by some Ubun­tu defaults, and still oth­ers — Gill Sans, Opti­ma, Caslon, Tahoma, and more — have decent sub­sti­tutes just wait­ing in the repos­i­to­ries. Typog­ra­phy plays a greater role in user expe­ri­ence than I think most peo­ple work­ing on Ubun­tu real­ize, and it should be a goal of 10.10 to ele­vate this part of the OS as much as pos­si­ble. This requires just a few extra kilo­bytes in pack­ages and some changes/additions to the files in /etc/fonts/conf.d/. In a sub­se­quent post I’ll be cat­a­loging what those changes should be.

Con­tin­ue →