So I'm working Saturday. At the office. I'm the only one here. And since it's Saturday, there is no air conditioning until 10 a.m.
I'm trapped in a large glass bottle of stale, hot air.
Update: It's 10:01. The air just kicked on. Half of any good employer-employee relationship involves free air-conditioning.
Just wanted to say that.
Am I really the only person having trouble with the Google Chrome web browser while running the propretary AMD Catalyst video driver in Linux?
I looked back in the archives and found out that I've been running Fedora on this particular laptop (HP Pavilion g6-2210us) for a year and two months.
Since this el-cheapo, about- AMD laptop is NOT a top-of-the-line Intel-running Thinkpad, it hasn't gotten anywhere near the same level of love from the Linux kernel and driver developers.
But things have gotten better and better over time. And excepting the relentlessly rolling Arch Linux, things improve more quickly in Fedora than anywhere else. New kernels, drivers and applications, for the most part, fly onto Fedora systems via regular updates.
Debian Developer Jon Dowland writes about switching from Linux to the Macintosh with OS X:
It appears I have switched for good. I've been meaning to write about this for some time, but I couldn't quite get the words right. I doubted I could express my frustrations in a constructive, helpful way, even if I think that my experiences are useful and my discoveries valuable, perhaps I would put them across in a way that seemed inciteful rather than insightful. I wasn't sure anyone cared. Certainly the GNOME community doesn't seem interested in feedback.
It turns out that one person that doesn't care is me: I didn't realise just how broken the F/OSS desktop is. The straw that broke the camel's back was the file manager replacing type-ahead find with a search but (to seemlessly switch metaphor) it turns out I'd been cut a thousand times already. I'm not just on the other side of the fence, I'm several fields away.
What can I say? With the Macintosh seemingly left for dead by Apple while the iPhone and iPad shovel in the revenue, Mac laptops have quietly become the platform of choice for developers everywhere.
Meanwhile, fragmentation in the Linux desktop space and what appears to be not just a lack of attention to detail but a willful rejection of it haven't helped.
That said, I'm firmly in the "buy cheap, run Linux" camp, and I figure that the Microsoft-driven laptop price war to combat the Google Chromebook will provide a whole new class of sub- machines on which to run the Linux distribution of your choice.
Since I don't have $1,500+ for a laptop that won't accept OS updates in a few years and generally don't need to run the Adobe Creative Suite, I don't have the opportunity/burden of trying to figure out how much free (as in freedom) software I could shoehorn into a Macintosh OS X environment.
But I can see how developers who aren't Linux distro developers want to go for what's "easy," if not at all cheap.
While Ubuntu has in the past tried to court developers, the current direction in which they're taking Unity is more about mobile compatibility than desktop productivity. And I don't see any advantages for the average developer with GNOME Shell. Maybe GNOME Classic in an environment with a whole lot more configurability out of the box would work. I know that a more polished Xfce with a lot of the rough edges smoothed out could be popular.
But it's the fragmentation ...
I'd love for Fedora Workstation with its (I think) target audience of developers to fill this gap. But without a long-term support release, that won't happen. Maybe a CentOS "developer desktop" spin could do better.
The elephant. In the room. It's the same thing it always was: Preloads.
It's going to require a major hardware vendor to commit to developer-centric laptops in a variety of price ranges with dedicated, in-house developers making sure the hardware is 100-percent supported in Linux and on the Linux distribution shipping with that hardware. I'm not saying it will never happen. I hope it does.
Until then, Apple is going to eat everybody's lunch, including Microsoft's. And desktop Linux's, too.
I'm not saying that choice on the Linux desktop is bad. What I am saying is that a stable, functional, not-scary desktop with some heavy development attention and (dare I say it) substantial corporate support could turn the tide and bring not just developers but others (back) to Linux.
Probably the best "solution" I've found for the lack of AMD Catalyst packages in RPM Fusion for Fedora 20 has been to use the packages that are still being maintained in that repository for Fedora 19.
But as always with proprietary driver packages, there is a question as to whether or not they will work with a new Linux kernel.
Kernel 3.15.3-200 moved recently into Fedora 20, and I decided to make the leap into installing it today.
I can report that
akmod-catalyst handled it perfectly. Catalyst works in 3.15.3, and everything is running as it should.
One of the touted features in kernel 3.15 is faster suspend/resume. Does using a proprietary video driver negate this speedup? I don't know.
I do periodically test suspend/resume with the open Radeon driver to see if I can ditch Catalys, but at this point I'll wait for live Fedora 21 (and Ubuntu 14.10) media for my next foray into the free driver.
I mentioned this in my CentOS 7 post but felt that it deserved to lead its own entry:
For those who want to run CentOS 7 on the desktop with minimal pain, take heart: Nux is prepping a CentOS 7 version of Stella
I was a big, big fan of Stella 6 -- I really think it's the only way to run CentOS on the desktop without pulling your remaining hair out. Nux has packages of just about everything you're missing in stock RHEL/CentOS. And for those who haven't really looked into it, RHEL/CentOS is missing a lot.
Stella isn't so much a derivative distro as it is a spin on CentOS that includes all the extra repositories you need to replicate the desktop experience of, say, Fedora, but in the supported-just-about-forever world of RHEL/CentOS.
In case you hadn't heard (and count me among that number until just about now), CentOS 7 is out.
One of the things that CentOS is planning to do in its cozy-with-Red Hat present and future is release a whole lot of specialized images.
One of those images is out right now. It's an "Everything" ISO image that fits on an 8 GB flash drive and offers every package in CentOS 7.
This is what that README file says about the "Everything" image:
This image contains the complete set of packages for CentOS 7. It can be used for installing or populating a local mirror. This image needs a dual layer DVD or an 8GB USB flash drive.
That README details the rest of the images available of CentOS 7, including the DVD-sized and minimal ISO images.
Want to download CentOS 7? Start here.
And for those who want to run CentOS 7 on the desktop with minimal pain, take heart: Nux is prepping a CentOS 7 version of Stella
The title of this post is long. It says it all.
I'd like easy file-encryption from the file manager in Fedora (and every other version of Linux, for that matter).
I'd prefer that encryption be strictly password-based and not dependent on encrypted keys that I might lose, but encryption with keys that I have safely backed up offsite is better than no encryption at all, so I'm going to try using the GNOME application Seahorse to try this out.
I'll even ignore that I'm not using GNOME and instead relying on the Thunar file manager in Xfce.
But I do have a full GNOME environment installed, and I'd use it more if GNOME would run under the AMD Catalyst driver in Fedora 20. That it does not should be a much bigger deal than it appears to be among the greater Linux user base.
Anyway, I do have Nautilus, and to make Seahorse work in that file manager, Fedora offers the
seahorse-nautilus package. I installed it just now and will be giving it a try in the very near future.
Update: After installing
seahorse-nautilus, it is possible to encrypt files via right-click in Nautilus, but there is no right-click option to decrypt a file.
There is a Fedora 17-era bug on this issue, which appears to have been resolved.
An answer on Ask Fedora provided a workaround, but I'm reluctant to try it at this time, though I should probably look into it for help in creating a "custom action" in Thunar so I can encrypt/decrypt directly from my chosen Linux file manager.