How to Make a Bootable Linux Thumb Drive via Command Line

This is another one of those things where I always have to consult my own notes because it never sticks in my head. Part of the reason for this is the fact that I am old fashioned and still insist on doing this the non-graphical way.

Why? Because graphical tools for such things often fail or provide unpredictable results at random, or don’t offer enough of the right options.

Also, because I really like the command line. Weird, I know. But use it enough, and you might like it too. You’ve been warned.

So… Beware, there is command line ahead. Don’t be afraid of it. Sometimes that’s the only reliable way to get something done when other tools break and fail.

And yes, for the Linux gurus who might be reading this, the post you’re about to read is kind of aimed at newbies. That’s okay, because people gotta learn somehow, right?

Advertisement

Xfce: Stop workspace hopping by browser

I’ve been using the Xfce desktop environment again lately, for the first time in years, because I was curious to see how it has changed over time.

As an overall, I’ve been enjoying this experiment; I was never very satisfied with it before for a variety of reasons, but its flexibility and stability are still attractive to me, and I’ve discovered that it’s better this time around than when I last gave it a shot.

That said, I’ve encountered an annoyance or two, and in figuring out the solution to one of the biggest ones, I thought I’d do a which howto and share it for reference.

How to downgrade Firefox to the last sane version (3.6)

So I keep ranting about Firefox here, and for good reason: the Mozilla team is going above and beyond the call of duty when it comes to driving users to other browsers.

However, try as I might, I simply encounter too many dealbreakers in Chromium.

When I think about it, the last version of Firefox that didn’t drive me crazy with crashing, incompatible add-ons, and stupid UI changes and features removed, it would have to be Firefox 3.6.

I keep forgetting how to do this, so I’m posting this here as much for my own reference as for anyone else’s. This is how to downgrade newer versions of Firefox to 3.6 and keep it that way, at least until things settle down a little, or until another browser comes along that can actually be a viable replacement for it — unlike newer versions of Firefox, sadly. This works with Mint 11, which means it will also work with Ubuntu 11.04.

My Firefox 4 setup process

For the last year and some change, I’ve gone from using Opera as my primary browser to using Mozilla Firefox. I have a variety of reasons for this switch, and it was a somewhat gradual one, but as I detailed in a recent post, despite it being my browser of choice, I still feel that it has a lot of shortcomings, and as such, it needs a lot of tweaking out-of-the-box before I find it usable.

So this is a writeup of the things I do to Firefox — in this particular case Firefox 4 — immediately after I install it. It used to be a much shorter list, but these days it’s getting more and more involved, so this writeup is as much for my own purposes, as a checklist of sorts, as it is to share my thoughts with others on how to tweak Firefox 4.

How to make Peppermint OS even faster with Openbox

A few weeks ago I posted a very early review of the new web-friendly Peppermint OS. In that review, I lauded the Peppermint team for achieving what I think might be the fastest graphical Linux distro I’ve ever tried, on any hardware.

The only things that get in my way of enjoying Peppermint are, unfortunately, the limitations imposed by the still-under-heavy-development LXDE desktop environment, which, while I’m still pretty excited about it, provides a few stumbling blocks to someone like me who likes to have more control over his user interfaces.

Well, for those of you out there who agree, I thought I’d do a quick writeup on getting the most out of Peppermint OS without having to resort to installing another desktop or window manager. Instead, we can make do with something that’s already integrated into Peppermint: the Openbox window manager!

Anatomy of a .desktop File

One of the beautiful things about Linux is that developers tend to be conscientious about the use of technical standards. Freedesktop.org maintains a wide series of standards for X Window System desktops, which apply to Gnome, KDE, LXDE and XFCE (I’m not sure whether Fluxbox implements these standards.) The standard for “desktop entries” is still technically a draft, but is generally accepted by the larger X community.

The .desktop file fills two primary functions: first, it informs the desktop environment how the file is to be handled by the desktop environment with regard to menu placement, display, environmental variables, and similar. In this function, it resides globally in /usr/share/applications/ and for specific users in $HOME/.local/applications. The second function is the direct shortcut on the desktop itself. In this function, it resides in $HOME/Desktop. The same file fills both functions, so if you want to have an application both in the menu and on your desktop, you’ll need to put the .desktop file in two places. Let’s take a closer look, shall we?

Remote X

Over at The Complete Geek my friend Jered posted a really nice howto on remote X11 forwarding the other day.

Like many of the uses of Synergy, remote X can be extremely useful when you’re working with multiple machines, or even if you’re working with a virtual machine and need to run some of the applications on the host without constantly flipping windows back and forth. One other useful application of remote X can be if you’re using a machine low on resources, it can act as a terminal of sorts, running remote X applications from other workstations.

Jered also points out how useful it is if you’re standing with one foot in the Windows world and one foot in the Linux world, because remote X can make that easier as well.

Give it a read, it’s a great writeup. The post can be found here: Remote X11.

Fluxconf: configuring Fluxbox the graphical way

Fluxbox is a window manager about which I have written a lot. The reason for that is because I use it every day, and I like it a lot. There’s a lot to like. It’s lightning fast, stable, and tweakable to a degree that will satisfy nearly every tinkerer when it comes to window managers.

But one of the biggest barriers to adopting Fluxbox for the “less tinkery” users out there is its configuration learning curve. Yes, Fluxbox is pretty simple when you get over the fact that you have to edit several configuration files by hand to set up your menu, your keys file, and other aspects. But for many users this is a big deal.

For some of those users, the answer to that dilemma is Fluxconf, a package of three applications that can be used to configure Fluxbox graphically.

Synergy: A software KVM switch (without the “V”)

A good friend of mine and fellow technology wizard has on several occasions brought up Synergy as a great solution for doing work spanning a couple of local workstations.

I know I have several times added it to my “Mental List Of Apps To Try”, but somewhere along the way I forgot about it. Last weekend Jered was over at my house for dinner and he brought it up again, and this time I installed it.

To make a long story short: I should have been playing with Synergy a long time ago!

For those who like to read a little bit more than that, continue, because I have a writeup.

Upgrading from KDE 4.2.4 to KDE 3.5.10 in Slackware 13

So a few days ago, Slackware 13.0 was released. Unfortunately, Patrick Volkerding greatly deviated from the basic philosophy to which he’s faithfully adhered for years with nearly every release — one of stability, simplicity, and only including elements in the distro that are thoroughly tested and functional — and replaced the highly stable, robust, and fully tested KDE 3.5.10 with the much less stable, buggy, half-baked and in fact barely usable KDE 4.2.4.

I wrote the other day that I considered this a minimum of a year or so premature, and had decided sight unseen that this was a bad decision, based on my extensive attempts at using KDE 4 releases as recent as 4.3 (on OpenSUSE 11.1).

Turns out I was right. KDE 4.2.4 on Slackware 13 is a disaster. I did a full install of Slackware 13 last night on VirtualBox and found KDE 4.2.4 to be just as unusable on Slackware as I had found it to be in Kubuntu when I tried it out a couple of months ago. Not surprising, since I didn’t expect that Patrick would have been fixing the massive usability issues intrinsic to KDE 4 just by including it in a Slackware release; that just isn’t a realistic expectation. Still, I had to get a baseline, and that baseline was about what I had expected.

Then, I set about finding a way to upgrade KDE 4.2.4 to KDE 3.5.10 on Slackware 13. I was successful in this today, and here is my writeup of how I did it.