Thursday, March 10, 2011

windows woes

It's days like today that I'm grateful I'm only a minimal Windows user... I decided to reformat my Windows XP virtual machine today, and I've spent half my day installing updates, rebooting, installing more, over and over again. I literally don't think I can count on one hand the number of times I've had to reboot. Which seems crazy to me considering I started out with SP3.

Then I get to deal with the frustration of downloading software that's bundled with other software I don't want. Take Adobe Reader, for example. First of all, it comes bundled with some Mcafee software I don't want. Thankfully that's an easy fix: I just uncheck a checkbox. But then, it tries to force me to install a browser plugin. Not seeing an easy way around that, after some Googling I found this page, where I could download the redistributable installation files, although (unless Adobe Reader's just really big), I'm pretty sure I ended up downloading way more than I needed. As if all that wasn't enough, it configures AdobeARM and Reader_sl to load on startup. I have no idea what they do, but I disabled them.

I'd prefer to use something like Foxit, but Adobe must be getting wise to the mass defections from their bloated software, because they seem to be continually inventing new ways to force you to use their software.

Then I look at my hard drive, and I've already used 10G, just for Windows itself, Forefront security client, vmware vSphere, and MS office. I really don't know how all you windows folks do it. I'm guessing it's because you haven't realized there's anything better out there (which in my opinion constitutes just about anything else) ;)

Well, gotta go. My VM just finished another batch of updates. I need to reboot and do it all over again...

Edit:
after posting this I realized it's pretty whiney. I probably should have waited until I was less frustrated to post. obviously not all of my complaints in this post even deal with windows itself, and are directed more toward crummy, bloated apps like Adobe Reader. of course, it's still nice that GNU/Linux only makes me reboot for kernel updates, and that it takes up less space :)

Wednesday, March 9, 2011

python's only problem: concurrency

python has its naysayers, but that's what jealousy will do to you :) seriously though, python does have one major issue: concurrent/parallel programming. now I'm no engineer, and I'm sure this is an oversimplification, but three ways of accomplishing this are:


  1. using multiple threads

  2. using multiple processes

  3. event-based programming



the main killer out of these three is trying to do multi-threaded programming in python. the short answer: don't. when Python was designed, it was given the philosophy that people using it should have to worry about as little as possible under the hood. while that's great, the way the python threading library was designed makes it inefficient for CPU-bound tasks. essentially, the more threads you use in python for CPU-bound tasks, the slower your code will be. ironically the problem seems to be even worse on machines with multiple processors. the problem has a name: the Global Interpreter Lock (GIL). you can read more about it here:

http://wiki.python.org/moin/GlobalInterpreterLock

there's also a great presentation that explains the problem pretty well if you have time to watch it. I'll put it at the bottom of this post.

then there's the issue of event-based programming. the problem in this arena (in my opinion, of course) is that there are too many choices for event-based programming, and none of them are included in the python standard library, so there's no standard as of yet.

lastly there's multi-process programming, which thankfully is in a better place than the other two. although it's only been fairly recently (within the last couple of years), python now has a multiprocessing module in the standard library. so if you're looking to write some concurrent/parallel code, I'd say start with here before wading through the alternatives that aren't in the standard library:

http://docs.python.org/library/multiprocessing.html

as the speed of computing becomes increasingly more about multiple processors than faster clock speed, the more important this issue will be. thankfully there's a standard solution (the multiprocessing module) as well as plenty of alternatives, and hopefully in the near future one or two of these alternatives will become standard, if not at least de facto.

here's a page that has links to some resources related to concurrency in python, as well as links to plenty of the afore-mentioned alternatives:

http://wiki.python.org/moin/Concurrency

and here's that video I promised:
[blip.tv ?posts_id=2243379&dest=-1]

Tuesday, March 8, 2011

Python and MySQL autocommit

Solution:

If your MySQL database is using the InnoDB engine, commit your changes after database transactions:
cursor.connection.commit()

Or just turn on autocommit to automatically commit after every database transaction:
cursor.connection.autocommit(True)

Details:

So I was using python's MySQLdb module to edit a mysql database, and I noticed that even though python was telling me my modifications were taking place, I wasn't seeing any changes. in addition, when I would log onto the database from something other than python and try to make changes, I would get this error:

ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction

Well apparently, the mysqldb module now disables mysql autocommit by default. so now, when I'm done with my transactions to the database, I need to commit my changes by calling the commit() function of the connection object. the connection object is what's returned when you call the MySQLdb.connect() function. I haven't really been using that object in my code other than to create the cursor object, which is what I normally use:

db = MySQLdb.connect(...)
cursor = db.cursor()

But the cursor can access the connection object, which I can then use to commit the changes:

cursor.connection.commit()

The strange thing with all of this is that I just started noticing this problem, even though according to the MySQLdb module authors, this functionality (disabling autocommit by default) has been in place since version 1.2.0 of the module. but when I look at the package versions of python-mysqldb for Ubuntu (what I'm currently using and have been for a while), it looks like it's been past version 1.2.0 for the last several years:
http://packages.ubuntu.com/search?keywords=python-mysqldb&searchon=names&suite=all&section=all

Maybe this "feature" has just recently made it into Ubuntu's package for this module. or maybe I'm missing something else here. at any rate, at least I know what's going on.

You can see here for more information:
http://mysql-python.sourceforge.net/FAQ.html#my-data-disappeared-or-won-t-go-away

Edit:
Okay, so apparently what happened is in my other code where I was modifying mysql databases, they used the default engine (MyISAM). the database I was having problems with was using the InnoDB engine, which is a transactional storage engine. this explains why I just now saw this issue.

More information here:
http://stackoverflow.com/questions/1617637/pythons-mysqldb-not-getting-updated-row

As well as an alternate solution: instead of committing after every transaction, I can turn autocommit on when I'm working with databases using the InnoDB engine, so they'll function just like the rest:

cursor.connection.autocommit(True)

Monday, February 28, 2011

Vala, Vala everywhere!

...okay, okay, maybe not everywhere. But since I posted on Vala a while back, I've noticed a couple of teams in particular seem to have embraced it wholeheartedly. What's really cool is that these teams have been writing some really impressive software for GNU/Linux in Vala. Nearly all of these software projects were started within the last year or two, and these aren't your grandma's Linux apps. These are sleek, fast, and have a strong focus on usability and a nice, clean interface. They're really worth checking out.

Here are the teams and their software:
  • Yorba
    • Shotwell (photo organizer)
      This one's extra impressive because in less than two years it's gone from brand new project to the default photo manager for top GNU/Linux distributions Ubuntu and Fedora
    • Lombard (video editor)
    • Fillmore (music recorder)

  • Elementary
    These guys started out creating slick themes for Ubuntu, and before long started making their own apps. They've started up so many software projects, particularly in the last year, I don't know how they could possibly have time to work on them all:
Elementary has another app named Dexter, an address book, and although it's currently written in Python, I wouldn't be surprised to see it go the way of some of their other apps like Purple.

There's also Midori, a lightweight browser, which I don't think the Elementary team started, but I know they contribute to it, and somehow or another Vala is involved, possibly due to their influence.

As if that wasn't enough, next month the Elementary team is releasing their own GNU/Linux distro, based on Ubuntu, but with a cleaner interface and packaged with many of their apps. Here's an early screenshot:

Thursday, February 17, 2011

Tuesday, February 8, 2011

Connecting to a Windows machine via RDP from GNU/Linux

For a while I used a program called Terminal Server Client (tsclient), a frontend for rdesktop, to connect to Windows machines from GNU/Linux using native Windows RDP. While it worked, it wasn't the greatest. For one, it seemed that in order to save my connection settings, I had to save a separate .rdp file for every server. And then if I wanted to connect to another server with its saved settings, I'd have to open the .rdp file for that machine. pretty annoying. In addition, when I would log out of the remote server, tsclient would present a popup saying that the connection was terminated, and after 30 seconds try to reconnect. Neither issue was a big deal, but it was kind of irritating. I confess that I never even looked for a solution to either one, so they both may have been easily solvable.

But now it doesn't matter, because I just stumbled upon a new RDP client called Remmina, thanks to this post. Remmina is quite nice, and solves both of the main issues I had with tsclient. Perhaps it will present some issues of its own, but so far, it's won me over.

I'm sure it's available in the repositories for most distributions. At the moment I'm using Ubuntu, and so to install it, I ran this in a terminal:
sudo apt-get install remmina

Here's a screenshot:

Saturday, February 5, 2011

Why I'm probably switching from Ubuntu, pt 3 (future)

In my last post, I discussed why the direction Ubuntu's taken recently has left me less than satisfied.

The future?

In short, I'm not really sure.

I think I've been using a Debian-based distro for so long that it'll probably be something along those lines. I did use Fedora for a while (6 months-ish) when I came to my present job. Honestly one of the most frustrating things was there seemed to be a major fracture in it's external repositories. Maybe I was just trying to install some weird stuff, but it seemed to me like a lot of what I wanted was in one repository, but some was in another, and the dependency conflicts eventually became too much. At any rate, at the time I was longing to get back to Ubuntu.

As far as Debian-based goes, the three that pop into my mind are:

  • Debian
    Switch from Ubuntu to Debian? Not unheard of, actually:

    Considering my major complaints with Ubuntu right now are stability and the new direction it's taking in terms of features, Debian would be a logical choice. At least from an outside perspective, it seems more balanced than the one-person (Mark Shuttleworth) distro that Ubuntu seems at times.

  • Mint
    I'm still not really sure why Mint exists, but to be honest I just haven't looked into it. The only advantage that I know of is that it's green instead of the ugly brown/purple that Ubuntu has used. A big disadvantage would be that I believe it's based on Ubuntu, so it may inherit many of the issues I have with Ubuntu right now. But I can't knock it til I try it.

  • Elementary
    Again, this one is Ubuntu-based, and so could inherit many of the issues I have with Ubuntu. But this one looks really amazing. I especially love the focus on simplicity. Sometimes when you have software written by geeks (and often for geeks) like GNU/Linux, simplicity gets lost in the quest for gobs of features. Quite often this ends up making me less productive, as I sift through buttons that I'll never use to find the one I want. But less really is more. And Elementary looks very promising.



Who knows what will happen. There's a strong chance I'll be too lazy to switch from Ubuntu, or that I'll try other options and come back. But Ubuntu definitely isn't on the pedestal it once stood. And maybe it's not the end of the world after all.

Subscribe to: Posts (Atom)