I thought you could take care of turning off suspend when the laptop lid is shut under GNOME 3 by using GNOME Tweak Tool. That doesn't work.

Automatic suspend when the lid is closed doesn't work for me because suspend/resume doesn't function on my HP hardware, and I'd like to close the damn lid every once in awhile without having to do a hard boot afterward.

It's the little things.

So I dug in a bit and found out in the Fedora Forum what you have to do (thanks to forum poster jvroig):

In a terminal:

su -
cd /etc/systemd/
gedit logind.conf

Once you're in logind.conf, uncomment (i.e. remove the #) on this line:

#HandleLidSwitch=suspend

Then change "suspend" to "lock"

It should now read like this:

HandleLidSwitch=lock

Save and close the logind.conf file.

Once you reboot, closing the lid should lock the screen and not suspend the laptop.

Note: Xfce doesn't suffer from the same inability as GNOME 3 to control what happens when you close the laptop lid.

Alternate instructions if you want to use vi and sudo:

Open a terminal and type:

$ sudo vi /etc/systemd/logind.conf

Change this line:

#HandleLidSwitch=suspend

to this (remove #, replace suspend with lock):

HandleLidSwitch=lock

Save and close the file in vi, then reboot.

It sounds screwy, but I'm taking some of the elements I like in GNOME 3 and Unity and implementing them in Xfce.

First of all, I really like the idea of having a panel on the left side of the screen for my application launchers. Given that laptops are now widescreen and there is not enough vertical space but plenty of horizontal space, it makes sense to have the application launchers consume as little horizontal real estate as possible.

So in Xfce, I moved the lower panel to the left. That was an easy one.

The other thing I like about both GNOME 3 and Unity is the ability to click the "Windows" or Super key and then type in the first few letters of an application to launch it.

Xfce already has a great application finder that does this. On Fedora with Xfce, it's configured to open with alt-F2 and alt-F3. I went into the Xfce keyboard configuration and set the Windows/Super key to open this same application finder. Now I can click Super/Windows, type in a few letters and have my desired app open without going through the menu. Just like in GNOME and Unity.

Of course my favorite apps are already in my panel on the left. But for those that are not, this is a nice feature to borrow/steal from GNOME 3 and Unity.

That Xfce can replicate this behavior says a lot about what you can do with this lightweight, stable and very configurable desktop environment.

As much as I love Debian, I have had less trouble running Fedora 18 and 19 than Debian Wheezy, video issues notwithstanding (as those are affecting me across all platforms).

Part of this, no doubt, may be due to improvements in Xfce 4.10 (the default in Fedora 19) over version 4.8 (in Debian Wheezy).

But overall Fedora's stability is remarkable, especially because it has a reputation for being less so.

So I noticed a BIOS option to turn the CPU fan off on my HP Pavilion g6-2210us. I tried it.

After invoking this in the BIOS, the fan didn't run all the time. It ran about half or more of the time. And the bottom of the laptop was appreciably hotter.

So I went back into the BIOS and turned the fan back to "always on."

Now the laptop runs cooler.

Obviously, right?

The fan isn't so loud that it's a problem, and it does have variable speed, so having it cycle off and on is more noticeable than just having it on all the time.

For reasons that escape me, AMD has changed the structure of its web site -- and changed the link where we all can find out about its latest Catalyst proprietary video driver for Linux:

Here is the new link.

From the bottom of that page, you can drill down to the specs on the latest beta driver.

As always, you can (and should) follow RPM Fusion's latest Catalyst (and Nvidia) packages.

I was reading today about how the Korora spin on Fedora includes Handbrake, the popular cross-platform video transcoding/DVD-ripping utility.

But I am running regular Fedora 19, albeit with proprietary-package assistance from RPM Fusion and a few other repositories.

Still, Handbrake isn't in any of those repos.

So I searched and found HandBrake for Fedora GNU/Linux on Sourceforge.

The installation from the RPM was quick, and now I have Handbrake.

In a very much related matter, Korora looks like a great way to get Fedora with all the multimedia bits set up for you. The distribution's What's Inside page discusses what Korora adds to Fedora in a sort of roundabout way.

Aside from automatic installation of all the multimedia codecs and outside repositories, Korora includes the Jockey proprietary driver manager, which I could really use given all the trouble I've been having with my AMD APU's video component.

The releases are popping out of AMD in hot/heavy fashion. Just about a week after the proprietary AMD Catalyst 13.10 beta video driver for Linux was released, today AMD's Web site is pushing the 13.11 beta.

Read the rest of this post

Update on Oct. 8, 2013: In the past day or so, AMD has revised its Radeon/Linux page to reflect that the Catalyst beta it is offering for download is version 13.10. Hopefully this means we are closer to a new stable release of the proprietary video driver as well as a new package from RPM Fusion (which you can watch for here).

Original entry from Oct. 2, 2013:

AMD has released a new beta of its Catalyst video driver for Linux.

You wouldn't know it by looking at AMD's Catalyst for Linux driver page (though the 13.8 beta link points to the 13.10 beta zip file).

But you would know it by looking at the separate page announcing the 13.10 beta.

Read the rest of this post

Maybe it's the company I keep (on Twitter and the Fedora Planet anyway), but I keep hearing about Docker and its use of Linux Containers to deliver stand-alone applications:

• Docker: an open source project to pack, ship and run any application as a lightweight container
• Marek Goldman: Docker and Fedora

More about Docker:

Docker is an open-source engine that automates the deployment of any application as a lightweight, portable, self-sufficient container that will run virtually anywhere.

Docker containers can encapsulate any payload, and will run consistently on and between virtually any server. The same container that a developer builds and tests on a laptop will run at scale, in production*, on VMs, bare-metal servers, OpenStack clusters, public instances, or combinations of the above.

...

* Please note Docker is currently under heavy developement. It should not be used production (yet).

Is it possible to synchronize a local filesystem (really a directory and everything below it) with a filesystem/bunch-of-directories-and-files on a server with an ftp client application like FileZilla?

What I'm looking to do is create files and directories on my local drive and then use the client application to automatically (or at least semi-automatically) upload those new items to the server without me having to "drag them over" in the FTP client. I want to keep both directories in sync, much like Dropbox does, but without a third-party service in the middle, and without needing to upload the whole directory and contents, but just the changed/new items.

On the FileZilla forum, it is suggested that the tool for this job is not ftp but rsync.

I use rsync all the time for my local backups, and I'm not terribly well-versed in using it with ssh over the network, but I will look into this and see what I can come up with.

Others are suggesting Unison (1), (2), (3), (4) (5), which builds on rsync.

To make a long story I don't yet understand a whole lot shorter, rsync works in one direction, Unison in both, which can be better for backups when things are potentially changing on both server and client (or server and server, for that matter).

Problem with Unison: You must have Unison on both systems, and my shared hosting account's CentOS box doesn't offer it. It does have rsync, so I might have to go with that. Or I could just continue with my current arrangement of either working with the server's filesystem mounted over sftp most of the time, pushing local files over sftp some of the time, and using sftp to pull down backups on a regular basis.

Possible solution -- Csync: Rob suggests in the comments below that csync could work for this task. It only needs to be on the client side, and it both pushes and pulls files.

I've already installed it, and I'll look into making it work.

What I'm trying to do is keep filesystems in sync across different systems where there are potentially new and changed files on both sides.