|
|
I got my N900 back. The micro-USB port had broken off cleanly. Apparently that's a known thing. I brought it to a Nokia Support Centre and they fixed it in two weeks. So far for the good news.
The bad news is that, even if they only reattached a connector, they still wiped the phone itself. I had a backup from the backup application and a dirvish backup of /home/user
But obviously that's not enough. First of all, restoring from the backup takes a while - it reinstalled 110 apps, 20 of which stopped the installation because they feel I should click ok to install. Sigh.
Transferring 30 GB of old data is slow no matter which way you cut it.
I lost my Angry Birds levels and the Sygic Mobile Maps app, still trying to figure out if I can get those back easily.
But at the moment I'm mostly annoyed at my problems figuring out why I can't ssh as user@ to the N900 anymore.
So, here are the steps I took:
$ sudo gainroot
# apt-get install sysklogd
# vi /etc/syslog.conf
(uncomment the line that says: auth,authpriv.* /var/log/auth.log)
# vi /etc/ssh/sshd_config
change LogLevel to DEBUG3
# killall sshd
(doing /etc/init.d/ssh restart does not actually get the job done; neither does initctl stop sshd)
# tail -f /var/log/auth.log
(finally the log is there)
try and log in
Now the log tells me:
Apr 7 12:51:31 Nokia-N900 sshd[2266]: User user not allowed because account is locked
And a quick look at /etc/passwd shows ! as the password, meaning the account is locked out.
So...
# passwd user
(pick a password)
then try and log in again using ssh keys, and now it works.
I had no idea a user needed a password before being allowed to log in with ssh keys (not using the password).
After this, don't forget to set logging back to INFO lest you fill up your limited disk space with useless debug info.
I got my N900 back. The micro-USB port had broken off cleanly. Apparently that's a known thing. I brought it to a Nokia Support Centre and they fixed it in...
I've been hacking on Paisley again recently since I found it I am not the only current maintainer. There is a branch on github from which a 0.3 release was recently made.
That's good news, because I didn't really need a new project to maintain. But I still have code I want to see land there, so I'm working on merging branches between launchpad, github, and some of my experimental svn branches here and there.
I had just implemented a cache for the object view mapping using couchdb-python's mapping.py and it turns out someone else was interested in adding memcache support to cache document lookups.
Some discussion started on a possible API, and I took a stab at a first draft over the past week.
Separately from that, I also took a CouchDB training course for work (together with Marek, one of our developers) ran by the Couchbase (company merger of CouchOne, formerly CouchIO (?) and Membase) people. That was a good training - but I digress.
At night Marek told me that they have some 300 lines of code that sadly reuses some classes from the current work codebase to set up and tear down test cases that work against an actual couchdb instance. He didn't feel like rewriting all that code to not use some of work's code just so that it could be contributed to Paisley for example. I felt I could do it in less than 100 lines, but he didn't seem to believe me.
So here I am after a magnificent Jose Gonzalez concert at the Palau de la Musica which is right around the corner from me, trying to write the caching code, and realizing I can't properly test it together with the change notification listener I wrote.
So while I was watching an episode of Breaking Bad, I wrote the setUp and tearDown code to do just that - start a couchdb instance on a random port, get the port, and connect to it.
It's probably not perfect yet (I do a busy loop for the creation and filling of the log file to read the port), but it worked for my simple test case. And it's 74 lines of code, including docstrings (which Marek for some reason does not believe in) and comments (which Marek also not believes in).
It's being worked on in this branch and I hope to land that in the paisley tree soon.
I've been hacking on Paisley again recently since I found it I am not the only current maintainer. There is a branch on github from which a 0.3 release was...
A few weeks ago my root hard drive died on the media machine at home. Time to do the upgrade dance on a new drive. I jumped from Fedora 11 to Fedora 14.
Boy was I in for a surprise display-wise - it felt like it was 2001 all over again.
I connect the media machine with an NVidia GeForce 6200 card and its VGA output to the big screen TV. That worked fine before, albeit with the proprietary NVidia drivers. I don't use the DVI output because I don't have a cable.
So, the monitor preferences only show resolutions up to 1024x768, when in Fedora 11 it had no problem doing 1920x1080. I tried to fiddle with some xrandr stuff adding modelines but didn't find anything that worked well. It was a bit of a pain too; you're supposed to be able to delete modes you added, but I just got
$ xrandr --rmmode "ATSC-1080-60p"
X Error of failed request: BadAccess (attempt to access private resource denied)
Major opcode of failed request: 149 (RANDR)
Minor opcode of failed request: 17 (RRDestroyMode)
Serial number of failed request: 27
Current serial number in output stream: 28
whenever I tried.
In the end I created a little script that made testing and adjusting mode lines easier for me, like so:
export DISPLAY=:0
export MODE="ATSC-1080-60p-5"
xrandr --newmode "$MODE" 148.5 1920 2000 2056 2200 1080 1082 1088 1125
xrandr --addmode VGA-1 "$MODE"
xrandr --output VGA-1 --mode "$MODE"
I tried to install the nvidia drivers from rpmforge. Sadly the latest kernel oopses on this machine (not sure yet why), and there were no built modules for the original Fedora 14 kernel release. After I realized that all older kernels are removed from updates and can be gotten from Koji, the build system, I was on my way to reboot into a working kernel with nvidia drivers installed.
Except that those only found 640x480 and 320x240 resolutions. And adding modelines using xrandr doesn't even work there.
Remove all nvidia drivers, reboot with a nouveau driver enabled, and tinker some more. None of the lines in this MythTV modeline database for Sonys actually worked. The ones I generated with cvt or gtf where displaced way to the right.
Eventually I stumbled upon this HTPC howto with an ATSC-1080-60p modeline that almost worked - the image was just slightly to the right. So, re-reading ESR's XFree86 modeline howto (after ten years or so ?) helped me do the final adjustments. Now just to make the settings permanent.
Of course, the proper fix would just have been to plug in a DVI to HDMI cable, and rely on EDID (which I assume works). Haven't bought the cable yet though. Neither my Sony TV nor my Sony amplifier have a DVI input, and I don't know of a way to pull in digital sound through a DVI to HDMI converter.
But I do wonder why the system was able to automatically detect and go to 1920x1080 in my previous (but broken) Fedora 11 setup...
A few weeks ago my root hard drive died on the media machine at home. Time to do the upgrade dance on a new drive. I jumped from Fedora 11...
Our team is working on this great new system. It's really cool even though I can't say much about it. They've been surprising me with some inventive stuff. I saw a cool testing tool last month that allowed simulating the whole system on one machine, and it worked, and it detected bugs in the code that they were then able to fix and test again.
But we can't find a good QA engineer to come help us make this thing really rock. Most QA curriculums I get are written in .doc or .docx, show the person having only very vague Unix knowledge, and think Python is a snake best stayed away from.
We contracted a QA consulting company, and after a four day audit they concluded that we were not doing a simple web framework and they did not have the skills to test our system.
I'm sure there's a great QA engineer out there eager to test our multi-datacenter multi-server cluster system doing cool stuff, with some QA experience, some SCRUM experience maybe, some Linux experience please, and some Python experience if possible. But most of all, with a desire to learn, and some capability to start out on his/her own in one project and slowly grow a QA team from the inside out.
Come on, I know you're out there. Send us a mail!
If you're interested, here's the job description.
Our team is working on this great new system. It's really cool even though I can't say much about it. They've been surprising me with some inventive stuff. I saw...
I have two projects on which I will eventually need some kind of file metadata management. One is my still-being-written music application, with one of its core features being distributed - I have three computers and a bunch of devices (like my phone) to put music on, and I want to stop doing that manually.
At its core it will need a distributed database (for example desktop couch) and some rules to decide what files to copy where.
A second application is yet to be started, and I hope it already exists and I can avoid having to write it. But at its core it would help me keep my offline backups up-to-date by indexing online data on all my machines, tracking a backup strategy for each machine and its folders (for example, documents and photos need really good backup, while downloaded iso's for fedora I can lose no problem), and telling me when I should bring an external drive from work and hook it up to the NAS because, according to the records, I have at least 100 MB of changes in important files that I care about.
If I am serious about wanting to avoid rolling my own, I should check what metadata projects exist out there, and the first one on the list is Tracker.
I'm surprised that, for all I've read about it on Planet Gnome I never actually tried to use it.
So, my initial impressions:
I'm going to let tracker sit and see if indexes something by tomorrow. It'd be great to use a tool that I know will get lots of love and care in GNOME.
I'm pretty sure underneath there's some excellent hacking, but for developers evaluating solutions to their problems the five minute out of the box experience is important. I think Tracker could do a few quick improvements and get some easy wins to get more people convinced.
I have two projects on which I will eventually need some kind of file metadata management. One is my still-being-written music application, with one of its core features being distributed...
« Previous Page — Next Page »
|