What's really interesting is that this is Adobe's first 64-bit release of Flash. That is, Linux users got it first, before users of Windows Vista x64 and and MacOS X. It probably does not mean anything, especially since Adobe has mentioned 64-bit flash will be released at the same time across platforms, but you can't help but feel good inside.
Go download it now and remember to report good bugs.
Update: Some quick notes...
Apparently, creating your own personal dictionary is ridiculous easy with aspell.
If your language is English, create a file in your home directory called ".aspell.en.pws":
personal_ws-1.1 en 0<br />Samat<br />quasirhombicosidodecahedronThe first line is a required header. Every subsequent line is a word you want to add to your dictionary. I can't believe I've let this sit for so long. Because it's a nice text file, syncing this file between machines to take your dictionary with you is trivially easy.
]]>I've found that putting the site into offline mode makes database backups go much faster on heavily trafficked sites (which is obvious). However, for a particular site I was working with, this needed to be done in an automated manner, and on a dedicated database server that did not have access to the Drupal installation.
Most people take their Drupal sites offline through Drupal's web-based administration interface. They can also be put offline through the Drupal Shell. Neither were suitable for me: the former cannot be automated easily, and the latter requires access to the Drupal installation. Fortunately, Drupal sites can easily be taken offline by setting things in the database, which can easily be done via bash scripts and the command-line MySQL client.
Given your database user is my_db_user, password my_password, and database my_drupal_db, the backup script would look something similar to:
#!/bin/bash<br /><br /># Take site offline<br />mysql --user my_db_user --password=my_password my_drupal_db << EOF<br />UPDATE variable SET value='s:1:"1";' WHERE name = 'site_offline';<br />DELETE FROM cache WHERE CID = 'variables';<br />EOF<br /><br /># Do stuff here while the site is offline (e.g. backup)<br /><br /># Bring site online<br />mysql --user my_db_user --password=my_password my_drupal_db << EOF<br />UPDATE variable SET value='s:1:"0";' WHERE name = 'site_offline';<br />DELETE FROM cache WHERE CID = 'variables';<br />EOFUpdate: The original version of this article had some problems on some setups with the variables table being cached. I added another SQL statement to make sure this cache is flushed so the site actually reflects its configuration.
Update: This method really doesn't work that well, and the more I think about it, there isn't a way to get around writing something that interacts with Drupal. I'm working on a script that will be more fool-proof.
]]>I'm a little bothered by this, as it forgeos all the "semantic desktop" work that has gone into KDE 4, namely what's provided by the Strigi and Nepomuk libraries. One thing the whole semantic desktop concept entails is that other applications will be able use data another application stored, but without care to what that other application was or how it was stored. For example, I should be able to share the list of all tracks in my music library, how many times I've played tracks, what tracks I think are my favorite, etc across music players. This kind of abstraction is, obviously, good for users, but bad for developers of proprietary software. They don't want you to easily switch between applications that they do not control. Amarok switching to it's own database store is a stab at this kind of desktop interoperability. I've my own thoughts to add, though, that support what the developers are doing...
Amarok is an awesome application. Dare I say, it's a killer application on Linux---on several occasions this past year I've recommended people install Linux just so that they could play with Amarok and see how much better it is compared to what they were using (yes, I'm looking at you, iTunes).
Before Amarok, I used Music Player Daemon (mpd). I stopped using it after a while: the playlist management wasn't very good; it would eat those playlists that I spent a lot of effort to make; the GUIs available at the time were lacking; and it was very slow when working with tens of thousands of songs. Some of this may have changed but I've not been motivated to look back.
Enter Amarok: I switched because the playlist management was so much better. I setup a MySQL server on my workstation to store metadata, as SQLite was much too slow. Amarok backed with MySQL is very fast---I dare others to find a library-based music manager that is faster with the number of songs I've thrown at it.
Balancing desktop interoperability with performance is a delicate balancing act. Interoperability is the hot thing these days---look at how Apple's line of integrated software and hardware continue to sip market share from the Microsoft-powered desktop. But when it comes down to it, performance and other more perceived benefits are going to win out over desktop interoperability. The Amarok developers' decision to go with MySQL embedded is a good one that will hopefully keep people moving to Amarok over proprietary alternatives.
]]>This article does not discuss configuring your mail filtering system (i.e. procmail, maildrop). This depends completely on your setup, and more than likely there are plenty of other articles that describe the best way to setup what you want.
]]>People want Linux on their Dell machines. Remember to click the "promote" icon and make your vote count.
]]>This is incredibly monotonous—and people have to wonder why Web of Trust-based encryption is not more popular?
The Debian signing-party package provides the utility caff to automate some of this. It's not very friendly to “desktop” users, however:
You could add authenticated SMTP or SMTP/SSL support to the script, but having to know how to hack Perl definitely disqualifies caffe from being a desktop-friendly application.
So, I hacked together my own key signing party script in Python that would send signed keys back to people via KMail. To use it, create a text file listing all key IDs you wish to sign, one per line. Pipe the contents of this list into the script:
cat list-of-ids.txt | key-signing-party-batch-process-via-kmail.pyThe script will download each key, ask you to verify the fingerprint, and then sign it. It then will open a KMail composer window, pre-filled with the key owner's e-mail address, a friendly template message (customizable in the script), and attached key. Review each e-mail to make sure it is kosher, and click send. Other than continuing to be a CLI program, I think this is much friendlier--the only manual work done is the creation of list of keys to sign, comparing fingerprints (this could be automated, but it seems in the spirit of the Web of Trust-based systems not to), and clicking send in a familiar desktop e-mail client.
Now for some notes...
It uses the DCOP automation features of KDE's Kmail to send messages. You could similarly use Evolution and D-Bus, but I don't use Evolution so I can't contribute that bit of functionality. Mozilla's Thunderbird unfortunately does not yet support any kind of automation features (as far as I know, anyway), so you're completely out of luck if you use it.
DCOP with Python is a complete, utter, pain. The easy way to drag-and-drop boiler-plate code with kdcop did not work, as it appears the APIs have changed. A problem with KDE/Python dcopext's module and multiple identically-named-functions sealed the deal for me and I gave up trying to use DCOP with Python, and instead settled for a hack of using the shell instead. I'm looking forward the one Linux desktop IPC protocol to rule them all, D-Bus, to debut in KDE4.
My script does not provide all the functionality of caffe. It, for example, does not encrypt the messages and their keys back to their owners. There doesn't appear to be an easy way to do this with KMail and DCOP, so it's a feature that will have to wait.
]]>