Many of my traditional blog post live on this site, but a great majority of my social-style posts can be found on my much-busier microbloging site at updates.passthejoe.net. It's busier because my BlogPoster "microblogging" script generates short, Twitter-style posts from the Linux or Windows (or anywhere you can run Ruby with too many Gems) command line, uploads them to the web server and send them out on my Twitter and Mastodon feeds.
I used to post to this blog via scripts and Unix/Linux utilities (curl and Unison) that helped me mirror the files locally and on the server. Since this site recently moved hosts, none of that is set up. I'm just using SFTP and SSH to write posts and manage the site.
Disqus comments are not live just yet because I'm not sure about what I'm going to do for the domain on this site. I'll probably restore the old domain at first just to have some continuity, but for now I like using the "free" domain from this site's new host, NearlyFreeSpeech.net.
MLED -- Microlinux Enterprise Desktop -- builds on Slackware for a 'full-blown production desktop,' but it's not as easy a rolling an ISO
MLED, aka the Microlinux Enterprise Desktop, is Frenchman Nicolas Kovacs' attempt to bring together various bits and pieces of the Slackware community, including Slackbuilds, slackpkg+ (which I confess I've never heard of until now) and more to create what he calls a "full-blown production desktop."
Yes, that includes multimedia codecs.
You get MLED by installing Slackware, then importing "tagfiles" (first time I've heard of this concept) and doing more than a bit of configuration, choosing KDE, Xfce or MATE along the way.
It's not as easy as a full-blown ISO but not as hard as finding all the bits on your own.
Kovacs talks about why MLED is based on Slackware here, and I agree with pretty much everything he says.
If you're looking for a long-term-support distribution with extremely conservative underpinnings, Slackware is a compelling choice, and it looks like MLED will get you from zero to desktop that much more quickly than assembling the bits on your own. I'd prefer this to be more automatic, but those are the Slackware-fueled breaks, I guess.
I've been using Fedora Linux for the greater part of this year, starting with F18 and upgrading via Fedup to F19. For most of that time, I've used the closed-source AMD Catalyst driver as packaged by RPM Fusion instead of the open Radeon driver that ships by default with Fedora and most every other Linux distribution.
I'm not proud of it. But the differences in performance are too big to ignore.
Things that stink with both drivers: Neither the open- nor the closed-source driver will resume my HP Pavilion g6-2210us laptop after suspend. (The machine uses the AMD A4-4300M APU with AMD Radeon HD 7420G graphics.)
Things that stink with the open driver: Only the Catalyst driver delivers working 3D acceleration, meaning without it I can't run GNOME 3 at all, most games look like hell, and a certain wonkiness crops up here and there on various web pages.
With Catalyst, my glxgears frames per second are 100 times greater than with the open driver. I don't know what glxgears fps numbers really mean, but 5,200 has got to be better than 50.
Things that stink with the closed driver: In Xfce, many application windows have lost the borders on the left and right sides. I can't explain it.
I also cannot successfuly use UEFI secure boot with the Catalyst-enabled kernel, though I can do so without Catalyst installed. It's not Secure Boot itself that is stopping the boot. It just hangs at some point -- after some IP tables lines in the dmesg, I think. The solution is keeping EFI but turning off Secure Boot.