I stopped using stand-alone mail clients about a year ago.
This week I decided to give Thunderbird another try. I'm keeping it simple this time around.
I'm using Thunderbird for a single e-mail account via IMAP. No Gmail. No shared Google Calendar. No newsgroups (yeah, I said newsgroups, which I had running in Thunderbird my last go-round)
What pushed me back to a mail client was the lack of speed in my webmail client of choice, RoundCube, with my mail provider.
So I'm keeping it simple and enjoying the speed and ease of a traditional desktop mail client.
Thunderbird has seen quite an update in its UI since the last time I used it, and that's enough progress for an app that has seemingly been abandoned by its parent company/foundation Mozilla.
As long as they keep it patched from a security standpoint, I don't need any new features.
I don't look on the OpenBSD Misc mailing list very often, but today a message from that list introduced me to Neomailbox, which offers services that include secure, encrypted e-mail and anonymous web surfing for prices that are very reasonable.
So why would you want to pay for e-mail? Well, you do get what you pay for, and while services like Gmail have a lot to offer, one of those things is Google's servers crawling the text of your mail and serving you ads based on what's in there.
And while Google is continually boosting its use of encryption, there are plenty of reasons why you might want an offshore, encrypted mail service that you actually pay for.
Did I forget to mention that Neomailbox uses OpenBSD?
Neomailbox also offers an anonymous web surfing service that uses encrypted tunneling and anonymous IP to add a whole lot of privacy and security to your daily comings and goings on the Internet.
And they do offer discounts if you get both e-mail and anonymous web, plus additional "family" discounts.
If your paranoid (or have reason to be) and don't want to run these services yourself on either home or colocated servers, Neomailbox is definitely worth a look.
You've heard the "Rhythmbox is dead" rumors. At various times over the past few years, the GNOME-centric music player, which I favor even in non-GNOME environments, has been called out for a lack of development, and replacements have queued up to take its place.
Well today a new Rhythmbox flowed onto my Fedora 20 system, and I took the opportunity to look at all of the fixes that went into the March 23, 2014 release of version 3.0.2.
I just installed Gvim, which is
vim-X11 in Fedora.
Maybe a graphical version of Vim will encourage me to use it more often.
That's the theory anyway.
I spent quite a bit of time running Google Chrome/Chromium on both Windows and Linux, but between feeling uncomfortable giving away so much data to Google (when logged in on Chrome) and how well Firefox performs on Linux (which is very well from what I can see), I now use Firefox about 99 percent of the time in Fedora 20.
But on my Windows 7 work machine, which is a more powerful (quad-core AMD to my laptop's dual-core, with 8 GB of RAM to the laptop's 4 GB), I flip it, using Chrome about 99 percent of the time.
So I've been switching it up to see how I might like using more Chrome in Linux and more Firefox in Windows.
I'll keep it short. There's nothing about Chrome on my laptop in Fedora 20 that makes me want to use it. It's no faster and no more stable. And SELinux doesn't much like it (and I get warnings).
I spent the whole day yesterday in Windows 7 on my big box running Firefox (version 27 on both machines for the record) for everything. It was measurably slower, and I had a few periods of non-responsiveness, especially with my customary 15-20 open tabs.
This means I'll be sticking with Firefox on my Linux-running laptop (and for my personal use, where I'm not so crazy about Google spying and Chrome on my workplace desktop, where I'm already using Google Apps and am not doing any personal business (and could care less if Google knows about my web use as it relates).
So I heard about an update to Skype for Linux (thanks, OMG!Ubuntu) that is supposed to fix some general noise and PulseAudio issues.
Since Skype's RPM for Fedora doesn't set up a repo, I had to download a new RPM from Skype and install it.
The new package, Version 22.214.171.124, runs as well as the old one. That means it fixed none of the audio issues I'm having, which include occasional noisy audio and intermittent lack of audio. The commonly accept fix doesn't help me, either.
Luckily I rarely use Skype, and usually only as an IM client, so I'll live.
For the freedom-lovers in the room, I did install the Ekiga softphone package in Fedora, and it kind of, sort of works. But the UI is HORRIBLE, and I doubt a non-geek could ever make it work. I need a better SIP package, and I'm open to suggestions.
I'm on the fence on this Skype fix for Linux distributions that use PulseAudio:
If you are packaging Skype for your distribution, you need to change the Exec line in your Skype .desktop file as follows: Exec=env PULSE_LATENCY_MSEC=60 skype %U If you are a user, and your distribution doesn’t already carry this fix (as of about a week ago, Ubuntu does, and as of ~1 hour from now, Gentoo will), you need to launch Skype from the command line as follows: $ PULSE_LATENCY_MSEC=60 skype
Using rootly privileges, I made this change in my
/usr/share/applications/skype.desktop file. It worked some but not all of the time. I'm more troubled by PulseAudio's use of CPU when I'm running Skype in the background but not actively using it.
I eventually reverted this fix in my
/usr/share/applications/skype.desktop file and am doing OK with the regular
Exec=skype %U line that is the default in my Skype installation.
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 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.
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.
Keep track of all Steve's development on his GitHub page, which I'm putting here more for me than for you.