Search Results: "cas"

11 May 2012

Andrew Pollock: [life] Zoe at 24 months

Once again, another 3 months have flown by. Honestly, it's been a total blur. What on earth has happened since February? Well, heaps more travel of course. There was the trip to New Orleans, which I already wrote about. The other big trip we did was to Washington D.C. for a week, which I'm yet to write up. We stayed with friends in Alexandria for the week. Unfortunately, Zoe came down with conjunctivitis before Sarah's very eyes on the flight over (I'd been in North Carolina for work the week before, so they flew without me and I flew up to D.C. to meet them). She also developed an ear infection and a general cough/cold. Fortunately, we caught it all pretty much as soon as it happened, and spent Easter Sunday at an Urgent Care in Virginia getting antibiotics for her, but her sleep was not so great the whole time we were in D.C. Other than that, we've just been doing the normal stuff. Swimming classes have continued (she's very confident in the water now). Her speech continues developing well. Toilet training is continuing to go very well. There haven't been very many accidents at all. She's really loving the "new" day care. It was definitely the right thing to do to move her. Physically, she's in the 80th percentile for height and the 50th percentile for weight, so I guess she's currently tracking to be on the tall and thin side of things. We had another birthday party in the park behind our home, and this year the weather was much nicer, so we had people hanging around until about 7pm, and a good time was had by all. Zoe even successfully blew out her candle on the first attempt. Her two-year molars still haven't come through. They seem to go through various stages of giving her a lot of grief, and then they stop messing with her sleep. I was beginning to think we'd never get back to an uninterrupted night's sleep ever again. It's still a bit hit and miss, but she usually settles down again fairly quickly if she does wake up, and doesn't always require intervention from us. I've arrived at the theory that the "terrible twos" are largely the fault of trying to cut these two year molars. Her tantrums are so much worse when her teeth are actively giving her trouble. If she's had a good night's sleep and her teeth aren't driving her crazy, she's still pretty well behaved. If she's been awake half the night and her teeth are hurting during the day, she can be quite difficult. We seem to be currently at a point where they're not causing too much trouble at night, but she'll chew on her fingers like crazy if given the chance during the day. I think seasonal allergies are also messing with her a bit. After she got over the cold she came down with in Washington D.C., she's still had a runny nose and a bit of a cough, but I don't think she's actually "sick" I think it's more related to allergies. She passed on whatever she had to me, and since I've recovered from it I'm also not feeling quite right. I read somewhere that pollen counts are off the charts this year due to the weird weather, and Sarah's having a bit of a hard time as well, so I think we're all going to just have to ride it out with the judicious use of antihistamines. Speaking of allergies, it's about time to re-test her for her egg allergy. We'll have to try that at a point when she's not regularly taking antihistamines for seasonal allergies, so it might be a while yet before we can do that. I guess the next big development will be graduating from the crib to a toddler bed. I'm not in any hurry to do that though, so as long as she's not escaping the crib, her sleeping arrangements can stay the way they are. It'd be nice if she can cut her teeth first and then once she's sleeping properly, we can try converting the crib into a toddler bed. Zoe walking down Castro Street in Mountain View

10 May 2012

Jo Shields: Sleeping with the enemy: my life with Windows Phone

In my last blog post about smartphones, I urged the universe at large to help maintain a variety of ecosystems, to help foster competition and originality amongst vendors and the same day I hit publish, WebOS was killed. Apparently the universe hates me. Since then, a few things have changed. My main phone since the day of its release was the HP Pre 3, running WebOS and whilst I still have a soft spot for the OS, the Pre 3 was simply too buggy for me to use full time. The main issue is that I use my phone as an MP3 player in the car but the Pre 3 would pause playback at the end of a track every half dozen tracks or so making it impossible to drive the 85 miles to work without needing to root around in the armrest and poke a touchscreen. Not something I really want to do whilst moving and ultimately too big a papercut to deal with. So, come the new year, I moved on to my next device, a Nokia N9 running MeeGo Harmattan. Ultimately, this was an even bigger failure for me than the Pre 3 was, and I lasted maybe two weeks with it before giving up and going back to the HP. Beyond massive usability errors in the software (especially the braindead unkillable pop-up demanding Internet access, even when none is available), the worst for me was how it handled the MP3 player task. My usual way of working is to have the phone hooked up to the stereo with a 3.5mm jack, and the car switches to headset Bluetooth profile to handle calls this is pretty common on cars too old to support A2DP profile (Stereo music-capable headphones). WebOS and Android are fine with this but not the N9. The N9, instead, will output all audio through the last connected audio device, regardless of how much that might not be helpful. Get in car, start music playing, plug in cable, start engine and it plays audio for about three seconds before the Bluetooth connects, and it switches to outputting music via the Headset bluetooth profile (not something that my car can do). Unplug and replug the cable, and music works but incoming calls are silent until I disconnect the 3.5mm jack, as it outputs the headset audio through the headphone socket. I just couldn t deal with this big a step back from WebOS as far as my workflow goes, and gave up. So, where next? Well, a funny thing happened a co-worker with generally very good instincts regarding consumer electronics usability told me that his housemate had just bought a Nokia Lumia 800 Windows phone (the WP7-based cousin to the N9) and loved it. Enough that said co-worker was considering getting one himself. This was a very strange thing to hear, especially from an iPhone owner, about a Microsoft product. I d been generally interested in WP7 on an academic level for a while, but to hear that degree of praise of the actual product was interesting. Also interesting, and roughly simultaneous, was seeing Sajid Anwar s reverse engineering of the proprietary Zune file transfer protocol go from theory into an actual set of libmtp patches. So if the capability to use Banshee to transfer music on is here or near and it can t be as braindead as Harmattan when it comes to headphone/bluetooth behaviour, then why not jump ship and squeeze a handset out of Orange? About a week after my co-worker replaced his iPhone with a Lumia 800, I bought one too. So where to begin? Well, I ll begin at the start: WP7 is a joy to use. It really just is. It s the first mobile OS to try something radically different in the UI department for years. Everyone else these days (especially Android) builds iPhone rip-offs to varying degrees, and even the iPhone interface has a lot in common with the old old OLD interfaces found on the dumb Nokia phones of the 1990s. WP7 has an interface which provides just the right level of passively visible information and interactivity, and manages to do it with an elegance that no Android home screen filled with widgets will ever manage. The uncluttered screens are easy to read, and the Metro usability paradigms are trivial to pick up and learn. Without a doubt I d recommend WP7 to friends and family from a usability perspective, and the Microsoft engineers and designers responsible for cooking up the WP7 interface are worthy of praise. And I m not the only one saying this Apple co-founder Steve Woz Wozniak recently came out with a similar line. That s the good. There s also some bad, make no mistake. I m going to cover all the reasons WP7 sucks over several paragraphs. But overall, a smartphone is a device which I expect to suck the question is how bad the suck is, and whether it gets in the way of me using the device for what I need at the time. Moreso than MeeGo, moreso than Android, and even WebOS (and I m still a big WebOS fan), WP7 has more good points than bad points. But there s still some room for improvement, and some room for caution and since I know there are a few Microsoft folks following me on Twitter, I m going to go over my prescription for continued platform success. Oh, one more thing before I start: I know WP7 isn t Free Software. As an end user, I really don t care about that. I just want something that works something I didn t get from WebOS and Harmattan, both of which are primarily Free Software stacks. I m not saying there s a causal relationship there, or that a mobile OS can t be both Free Software and good just that as an end user, my favourite platform right now is non-Free. Take from that whatever you like. It s also vitally important, as Free Software folks, never to lose sight of what the other players in the market are up to. If you can t objectively assess why people are using a proprietary option by using it & recognising its good points (i.e. what to steal & what to improve) then you can t hope to win over users. So. WP7 s downsides in detail. In-place updates. Seriously guys, even Apple can manage this now. Why can t Windows Phone? I understand that making backups is smart and all updates come with a mandatory backup but I really shouldn t be tied to a PC to update a post-PC device. Also, those backups are useless, since they cannot be restored onto replacement devices in the case of failure or theft, so fix that too. Update all the things. An iPhone sold in June 2009 still has access to the latest iOS releases. Android phones are notorious for shipping with an outdated version of the OS, then getting at most one major update over the phone s lifetime (usually the device is abandoned by its manufacturer within months of release). Which camp does Microsoft want to align with, there? Every Windows phone 7 device released should receive Windows Phone 8, even with some features disabled. Anything less is punishing every existing customer, in the hope that you ll attract new ones not a winning strategy for a fringe platform whose biggest evangelists are its users. Fix IMAP. IMAP isn t hard. Yet WP7 never seems to work properly with a subset of my mail, never showing the message body & just saying Downloading forever. Fix it. Bing sucks. Bing s search results are terrible. Either do something to make them bearable, or allow me to pick which search engine I get when I hit the search button. A Google live tile isn t the same thing. Make killing apps easier. I know you stole the WebOS card view for multitasking (hold the back button) please also steal the WebOS ability to close apps. I don t want to have to go into an app and bash back repeatedly until it quits. This is particularly annoying for Internet Explorer. Make reinstalling apps easier. If I want to install every app I previously had installed on a new device, without restoring a backup, this should be easy. There are third party apps which try to plug this gap. Find a way to support copyleft. I d like to port a few C# apps to WP7, but because they re LGPL, I can t. The code s copyright holders would have no issue with their code being on WP7, as long as end users have a mechanism to replace the libraries, so why not find a way to allow this? e.g. when compiling an app, let me mark a library as user-replaceable , then allow for some mechanism where an end user can replace those assemblies with their own version. Let me use multiple Google calendars. WP7 only lets me add/see appointments on my default Google calendar. I want to add/see things on my wife s calendar, which is shared with me. WebOS can do this. MTP-Z is the devil. I do not need or want encrypted end to end communication between my PC and my camera device, to transfer a photo off. I do not need or want encrypted end to end communication between my PC and my MP3 player to transfer a photo on. Let s be honest, the only reason for MTP-Z is to enforce DRM on Zune-rented music tracks and honestly, there s no good reason to require MTP-Z for *all* communications if all you want to do is protect one folder or file extension. Now, since MTP-Z theoretically forces me to use Zune for many tasks better handled by other apps, now I get to write multiple criticisms of Zune s desktop app and as long as MTP-Z is enforced, every Zune failing is a Windows Phone failing too. Zune: Support Windows codec infrastructure, and transcode where needed. Windows Media Player can play Ogg Vorbis files. No, not out of the box, but if one installs the required codecs. Zune should support the same files as WMP if you want to ensure people don t try to copy files to a portable device which are not supported on that device, then you should have an API in place to allow for pluggable seamless transcoding of files as required Banshee allows me to do this (e.g. to copy files I have as .flac to devices which do not support it). Zune: Search my tracks, not the web. Zune s searching is terrible it doesn t do as-you-type searches, and when I hit enter, matches from my collection are given a tiny little space compared to matches from the Zune music store. Let me easily pick the track I feel like listening to, don t make it a chore Zune: Let s solve metadata together. I absolutely love how nicely the Zune app on desktop and on phone shifts as appropriate to the currently playing artist (e.g. changing the lock screen to an image of the artist in question). However, Zune doesn t make it obvious how to set an album s metadata to support this, and it s particularly frustrating when it s a minor difference of spelling causing a track not to get the nice treatment e.g. UNKLE versus U.N.K.L.E. . Either start making heavy use of audio fingerprinting services like MusicBrainz to fill in metadata, or allow me to search for fully supported artists when filling in track metadata Zune: Random playlists are useless on devices. I like smart playlists. In Banshee, I have one to pick 12GB of random tracks, which I can sync to my phone. I can t do this with Zune. If I try to just sync all my random music to my phone, it errors out due to lack of space. If I have a random playlist, the random selection changes multiple times during a sync resetting the sync, wiping out half the tracks that were transferred on, and starting again. As a result, the sync goes on for literally hours, never ending up with more than a gig or so of tracks on the phone. Random playlists should be freezable, so I can transfer them to my device in peace, then get a new random selection when I want. So, that s my list of miserable failure and it s still a less painful list than any other mobile OS I ve used. Perhaps one day Android will approach being usable, perhaps Blackberry s BBX will actually appeal to human beings rather than corporate IT managers, and perhaps Mozilla s delightfully named Boot to Gecko will get some traction. Who knows. All I know is, My Lumia 800 is the best phone I think I ve ever owned, and it s important for anyone working in the mobile space to understand why.

Michal Čihař: Weblate 1.0

After few weeks of heavy testing, Weblate 1.0 has been released today. Compared to 0.9 there are just minor changes and bug fixes. The most important thing is that Weblate should be now really ready to use :-). Full list of changes for 1.0: You can find more information about Weblate on it's website, the code is hosted on Github. If you are curious how it looks, you can try it out on demo server. You can login there with demo account using demo password or register your own user. Ready to run appliances can be found in SUSE Studio Gallery. Weblate is also being used https://l10n.cihar.com/ as official translating service for phpMyAdmin, Gammu, Weblate itself and others. If you are free software project which would like to use Weblate, I'm happy to help you with set up or even host Weblate for you (this will be decided case by case as my hosting space is limited).

Filed under: English Phpmyadmin Suse Weblate 0 comments Flattr this!

6 May 2012

Russell Coker: A Quick Review of the Mac Mini with OS/X Lion compared to Linux

A client just lent me a new Mac Mini with OS/X Lion to play with. I think it s interesting to compare it with regular PCs running Linux. Hardware The Mac Mini is tiny. It s volume can be compared to that of a laptop. The entire outside apart from the base is made from aluminium which helps dissipate heat, it s not as effective as copper but a lot better than plastic. The ports on the system are sound input/output, 4*USB, Ethernet, Firewire, Thunderbolt (replacement for Firewire), SDXC, and HDMI. It ships with a HDMI to DVI-D adapter which is convenient if you have an older monitor (or if you have a recent monitor but no HDMI cable as I do). To open the case you unscrew the bottom, this is much like opening a watch. Also like opening a watch it s not particularly easy to screw it back on tightly, I will probably return the Mac Mini without managing to completely screw the base in. The hardware is very stylish and intricately designed, what we expect from Apple. It s also quiet. In every way it s a much better system than the workstation I m using to write this blog post. The difference of course is that this workstation was free and the Mac Mini cost just over $1000 including the RAM upgrade. A Mac Mini could be a decent Linux workstation and if I see one about to be recycled I ll be sure to grab it! Installation The Mac OS comes pre-installed so I didn t get to do a full installation. When I first booted it up it asked me if I wanted to migrate the configuration from an existing server, I don t know how well this works as I don t have a second Mac system but the concept is a good one. Maybe having full support for such a migration process would be a good release goal for a Linux distribution. After determining that the installation is a fresh one I was asked for a mac.com email address or other form of registration. I skipped this step as I don t have such an email address, but it could be useful. Red Hat has Kickstart to allow configuration of an OS install based on a file from a server (via NFS or HTTP). Debian supports preseeding to take OS configuration options from a file at install time [1] and the same option can be used for later stages of OS autoconfiguration. One thing that would be really useful is to allow the user to enter a URL for configuration data for an individual account or for all accounts, so someone with an account on one workstation could upload the configuration (which would be either encrypted or sanitised to not have secret data) and then download it when first logging in to a new system. I can easily take a tar archive of my home directory to a new system, but people like my parents don t have the skill to do that. One of the final stages of system configuration was to identify the keyboard. The system asked me to press the key to the right of the left shift key and then the key to the left of the right shift key and then offered me three choices of keyboard. That was an interesting way of reducing the list of possible keyboards offered to the user and thus preventing the user from selecting one that is grossly incorrect. Cloud Storage When first logging in I was asked for an iCloud [2] login. iCloud doesn t seem like a service that should be trusted, it s based in the US and has been designed to facilitate access by government agencies. Ubuntu One [3] is a similar service that is run by a more reputable organisation, but the data is still stored by Amazon (a US corporation) which seems like a security risk. Ubuntu One isn t in Debian (which is strange as Ubuntu is based on Debian) so it was too much effort for me to determine whether it encrypts data in a way that protects the users against US surveillance. The cost of Ubuntu One storage is $4 per month with music streaming. A better option is to use a self-hosted OwnCloud installation for a private or semi-private cloud [4]. A cheap server from someone like Hetzner (E49 per month for 3TB of RAID-1 storage) [5] is a good option for OwnCloud hosting. A cheap Hetzner server is about $US64 per month (at current conversion rates) which is equivalent to about 16 users of Ubuntu One for music streaming. So if 20 people shared a Hetzner server they could save money when compared to Ubuntu One while also getting a lot more storage. I ve got about 300G of unused disk space on the Hetzner server that hosts my blog and when the system is migrated to a newer Hetzner server with 3TB disks it will have 2.5TB of unused space, I could store a lot of cloud data in that! The main features of iCloud and Ubuntu One seem to be distribution of random data files (anything you wish), streaming music to various playing systems, and copying pictures from phones as soon as they are taken. These are all great features but it s a pity that they don t appear to support distributed document storage. Apple Pages apparently allows documents to be immediately saved to the cloud. I d like to be able to save a file with Libre Office at home and then access it from my netbook using the cloud, of course that would require encryption for secret files but that s not so hard to do. One advantage with such distributed storage is that when combined with offline-IMAP for email it would almost entirely remove the need for backups of the desktop systems I maintain for my relatives. I could have all their pictures and documents go to the cloud and all their email stay on the server so if their desktop PC dies I could just give them a new PC and get it all back from the cloud! OwnCloud supports replication, so if I got two servers I would be covered against a server failure. But I think that for a small server with less than a dozen users it s probably better to just take some down-time when things go wrong and do regular backups to an array of cheap SATA disks. App Store Apple has an App Store in the OS. The use of such a store on a desktop OS is a new thing for me. It s basically the same as the Android Market (Google Play) but on the desktop. I think that there is a real scope for an organisation such as Canonical to provide such a market service for Linux. I think that there is a lot of potential for apps to be sold for less than $10 to a reasonable number of Linux users. A small payment would be inconvenient for the seller if they have to interact with the customer in any way and also inconvenient for the buyer if they are entering all their credit card details into a web site for the sale. But for repeat sales with one company being an intermediary it would be convenient for everyone. A market program for a desktop Linux system could provide a friendly interface to selecting free apps from repositories (for Debian, Ubuntu, Fedora, or other distributions) and also have the same interface used for selecting paid applications. Conclusion This isn t much of a review of Apple OS/X or the Mac Mini. Thinking about ways of implementing the best features of Lion on Linux is a lot more interesting. I admire Apple in the same way that I admire sharks, they are really good at what they do but they don t care about my best interests any more than a hungry shark cares about me. Update I got the currency conversion wrong in the first version of this article. It seems that to save money via a shared Hetzner server instead of Ubuntu One about 20 users would be needed instead of 10. But that s still not too many and would still give a lot more storage. It would be a little more difficult to arrange though, probably anyone who is seriously into computers knows 10 people who would want to share such a service (including people like their parents who want things to just work and don t understand what s happening). But getting 20 people would be more difficult. Related posts:
  1. Xen and SE Linux EWeek review of RHEL5 The online magazine EWeek has done a review of RHEL5....
  2. Servers vs Phones Hetzner have recently updated their offerings to include servers with...
  3. Modern Laptops Suck One of the reasons why I m moving from a laptop...

5 May 2012

Russell Coker: Liberty and Mobile Phones

I own two mobile phones at the moment, I use a Samsung Galaxy S running Cyanogenmod [1] (Android 2.3.7) for most things, and I have a Sony Ericsson Xperia X10 running Android 2.1 that I use for taking photos, some occasional Wifi web browsing, and using some applications. Comparing Android Hardware The hardware for the Xperia X10 is better than that of the Galaxy S in many ways. It has a slightly higher resolution (480*854 vs 480*800), a significantly better camera (8.1MP with a flash vs 5MP without), and a status LED which I find really handy (although some people don t care about it). The only benefit of the Galaxy S hardware is that it has 16G of internal storage (of which about 2G can be used for applications) and 512M of RAM while the Xperia X10 has 1G of internal storage and 384M of RAM. These are significant issues, I have had applications run out of RAM on the Xperia X10 and I have been forced to uninstall applications to make space. Overall I consider the Xperia X10 to be a significantly better piece of hardware as I am willing to trade off some RAM and internal storage to get a better resolution screen and a better camera. The problem is that Sony Ericsson have locked down their phones as much as possible and they don t even give users the option of making a useful backup they inspired my post about 5 principles of backups [2]. The fact that the Galaxy S allows installing CyanogenMod which then gives me the liberty to do whatever I want with my phone is a massive feature. It outweighs the hardware benefits of the Sony Ericsson phones over Samsung phones prior to the Galaxy Nexus and Galaxy Note. For an individual user the ability to control their own hardware is a feature. Such an ability wouldn t be much use if there wasn t a community of software developers, so if you buy an Android phone that isn t supported by CyanogenMod or another free Android distribution then whether it is locked probably won t matter to you. But for any popular Android phone that s sold on the mass market it seems that if it s not locked then it will get a binary distribution of Android in a reasonable amount of time. Comparing with Apple It seems that Apple is the benchmark for non-free computing at the moment. The iPhone is locked down and Apple takes steps to re-lock phones that can be rooted as opposed to the Android vendors who ship phones and then don t bother to update the firmware for any reason. The Apple app market is more expensive and difficult to enter and if an app isn t in the market then you have to pay if you want to install it on a small number of development/test phones. This compares to Android where the Google market is cheaper and easier to enter and anyone can distribute an app outside the market and have people use it. But for an individual this doesn t necessarily cause any problems. I have friends and clients who use iPhones and are very happy with them. In terms of software development it s a real benefit to have a large number of systems running the same software. As Apple seems to have higher margins and larger volume than any other phone vendor as well as shipping only one phone at any time (compared to every other phone vendor which seems to ship at least 3 different products for different use cases) they are in a much better economic position to get the software development right. As far as I can tell the hardware and software of the iPhone is of very high quality. The iPad (which has a similar market position) is also a quality product. The fact that the Apple app market is more difficult to enter (both in terms of Apple liking the application and the cost of entry) also has it s advantages, I get the impression that the general quality of iPhone apps is quite high as opposed to Android where there are a lot of low quality apps and many more fraudulent apps than there should be. The lack of choice in Apple hardware (one phone and one tablet) is a disadvantage for the user. There is no option for a phone with a slide-out keyboard, a large screen (for the elderly and people with fat fingers), or any of the other features that some Android phones have. The lack of a range of sizes for the iPad is also a disadvantage. But it seems that Apple has produced hardware that is good enough for most users so there aren t many complaints about a lack of choice. It seems to me that the biggest disadvantage of the closed Apple ecosystem is for society in general. Anyone who wants to write a mobile app to do something which might be considered controversial would probably think twice about whether to develop for the iPhone/iPad as Apple could remove the app at a whim which would waste all the software development work that was invested in writing the app. Google seem to have much less interest in removing apps from their store and if they do remove an app then with some inconvenience it can be distributed on the web without involving them so the work won t be wasted. How Much Freedom Should a Vendor Provide? The Apple approach of locking everything down is clearly working for them at the moment. The Samsung approach of taking the Google prescribed code and allowing users to replace it is good for the users and works well. The Sony Ericsson approach of taking the Google code, adding some proprietary code, and then locking the phone down is bad for the users and I think it will be bad for Sony Ericsson. People are more likely to tell others about negative experiences and negative reviews are more likely to be noticed than positive reviews. So while many people are reasonably happy with Sony Ericsson products (until they find themselves unable to restore from a backup) it s still not a good situation for Sony Ericsson marketing. It seems that there are benefits to hardware vendors for being really open and for locking their users in properly. But being somewhat open isn t a good choice, particularly for a vendor that ships poor quality proprietary apps such as the Sony Ericsson ones. In terms of application distribution Google isn t as nice as they appear. The Skyhook case revealed that Google will do whatever it takes to prevent apps that compete with Google apps from being installed by default [3]. Google is also trying to make money from DRM sales via Youtube which it denies to rooted phones [4]. Again it seems to me that the best options here are being more open than Google is and being as closed as Apple. Google might gain some useful benefits from applying DRM (even though everyone with technical knowledge knows that it doesn t work) but the Skyhook shenanigans have got to be costing Google more than it s worth. How to make Android devices more Free The F-droid market is an alternative to the Google App market which only has free software [5]. On it s web site there are links to download the source for the applications, including the source and binaries for old versions. In the Google App market if an upgrade breaks your system then you just lose, with F-droid you can revert to the old version. A self-hosted OwnCloud installation for a private or semi-private cloud [6] can be used as an alternative to the Google Music store as well as for hosting any other data that you want to store online. The Open Street Map for Android (Osmand) project provides an alternative to the Google Map service [7]. Osmand allows you to download all the vector data for the regions you will ever visit so it can run without Internet access. But it doesn t have the ability to search for businesses and the search for an address functionality is clunky and doesn t accept plain text, which among other things precludes pasting data that s copied from email or SMS. While Osmand provides some important features that Google Maps will probably never provide, it doesn t provide some of the most used features of Google Maps so uninstalling Google Maps isn t a good option at the moment. The K9mail project provides a nice IMAP client for Android [8]. Use K9 with a mail server that you run and you won t need to use Gmail. There are alternatives to all the Google applications. It seems that apart from the lack of commercial data and search ability in Osmand an Android device that is used for many serious purposes wouldn t lack much if it had no Google apps. Google seems to be going too far in controlling Android. Escaping from their control and helping others to do the same seems to be good for society and good for the users who don t need apps which are only available in proprietary form. Related posts:
  1. Dual SIM Phones vs Amaysim vs Contract for Mobile Phones Currently Dick Smith is offering two dual-SIM mobile phones for...
  2. My Ideal Mobile Phone Based on my experience testing the IBM Seer software on...
  3. Old Mobile Phones as Toys In the past I have had parents ask for advice...

3 May 2012

Gintautas Miliauskas: Online Haskell typechecker

Last weekend I put up haskellonline.org, which is basically a thin web frontend over ghc, the Haskell compiler. It is limited to one Haskell module, but it makes the experience of studying Haskell much more pleasurable by running the typechecker in the background as you type. Plus, it is web-based - no local installation necessary!

The thing about Haskell is that it has a fabulous type system which can weed out a broad class of bugs at compile time. However, the usual interfaces with the compiler leave a lot to be desired. Vim + ghci in a terminal of course works, but I have already been spoilt by IDEs, and the "Alt-Tab; Up; Enter; wait; Alt-Tab + jump to line manually" dance does not appeal to me at all. Emacs integration might be better, but I do not know emacs well, and it is never a good idea to start learning two things at the same time.

Note: I suspect that many of the problems I encountered were due to the fact that I use MacOSX.

I have looked a few of the existing IDEs, but that did not go well. EclipseFP did not offer any benefits over a text editor at all. I found a blog post saying that implied that it would work better with a newer version of GHC. Cue a few hours of reinstalling GHC and compiling Haskell packages, and I got the system set up, but that made the situation even worse. Eclipse would simply crash on startup every time until I wiped the configuration directory clean. So much for EclipseFP.

I also tried Leksah. At least it did not crash, nevertheless, I found it quite unwieldy, especially for learning purposes. The autocompletion is broken in annoying ways. For example, if you type "f a = a<enter>", Leksah will autocomplete the second "a" into "as". It took me a while to discover an error in my program that was due to this autocorrection mechanism.

Leksah does have a "compile in background" mode, which was admittedly a source of inspiration for haskellonline.org, but the implementation is subpar. It simply invokes the compiler and simply redirects the output to a display pane on the window. As you write code, the text in the pane constantly scrolls, which is very distracting. The implementation is also buggy. Occasionally errors are interleaved with status output:


There is also tryhaskell.org, but it does not work not nearly as well for Haskell as its cousins trypython.org and tryruby.org do for Python and Ruby, respectively. All are limited to evaluating expressions, but in Python/Ruby that actually gets you a long way, while nontrivial Haskell programs are complex static structures that are unwieldy without a persistent text editor.

Despite all the trouble, which, again, probably has to do with my choice of MacOSX, these issues do not detract from the beauty of Haskell as a language. If you are interested, I can heartily recommend learnyouahaskell.com as very good reading material, and Tony Morris's course exercises (in combination with haskellonline.org) for practice.

Rudy Godoy: FLISOL Puno

Past Saturday April 28 I attended to the FLISOL 2012 Puno hosted at the Casa de la Cultura in downtown Puno. It was a great experience to deliver a talk after a while, the second speech since I enrolled into the UCSP s Computer and Engineering Faculty to get my Computer Science BS degree. Puno is really a nice city with a great landscape for those like me who enjoy the sun, lakes, wonderful mountains and, as it s name says, the Andes plane 3860m above sea level. Pretty high and very cold at night indeed but a lovely place. FLISOL is short for Latin American Free Software Installation Festival that just aged 12 this year. In my talk I wanted to describe the motivations behind the Free Software movement origins. I specially remarked the fact that the movement doesn t look for technical excellence, even though this is something we thrive for, rather than preserving a common set of guidelines for protecting assets we do value such software and freedom. Later I discussed about how Debian have become a key actor in the free software ecosystem. Primarily as a huge software library, second as a building block for specialized distributions (such as Ubuntu) and third, but not the last, as a facilitator for new developments and contributions to the ecosystem, and I mentioned here the Debian GNU/Hurd project. Through such topics I explained what we do, why we do it and why they may want to contribute. There was a good reception from the audience and there were many questions on the subjects I elaborated on. I was impressed to see many Debian users, some of them power users , and even tried to help one to configure his obscure Xorg settings on his laptop (didn t succeed because lack of connectivity, will send him testing CDs eventually). I d like to thank to the organization who made a great job. The team, nearly 30 students from Universidad Nacional del Altiplano plus local activists, started working in February collecting funds and managed to gather more than 330 attendees during the almost 10 hours of the event. Also special thanks for the coffee machine that was available!

2 May 2012

Matthew Garrett: Anatomy of a Fedora 17 ISO image

My spare time has been limited lately, so progress on producing Mac-bootable Fedora install images has been a bit slow. Thankfully it looks like everything's gong to land in time for Fedora 17[1] so hurrah for that - all that's missing right now are the last couple of patches that make sure the boot picker displays useful labels on the drives.

So how is this accomplished? Here's a hex dump of the first few K of the image.
00000000  45 52 08 00 00 00 90 90  00 00 00 00 00 00 00 00   ER.............. 
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................ 
00000020  33 ed fa 8e d5 bc 00 7c  fb fc 66 31 db 66 31 c9   3...... ..f1.f1. 
00000030  66 53 66 51 06 57 8e dd  8e c5 52 be 00 7c bf 00   fSfQ.W....R.. .. 
00000040  06 b9 00 01 f3 a5 ea 4b  06 00 00 52 b4 41 bb aa   .......K...R.A.. 
00000050  55 31 c9 30 f6 f9 cd 13  72 16 81 fb 55 aa 75 10   U1.0....r...U.u. 
00000060  83 e1 01 74 0b 66 c7 06  f1 06 b4 42 eb 15 eb 00   ...t.f.....B.... 
00000070  5a 51 b4 08 cd 13 83 e1  3f 5b 51 0f b6 c6 40 50   ZQ......?[Q...@P 
00000080  f7 e1 53 52 50 bb 00 7c  b9 04 00 66 a1 b0 07 e8   ..SRP.. ...f.... 
00000090  44 00 0f 82 80 00 66 40  80 c7 02 e2 f2 66 81 3e   D.....f@.....f.> 
000000a0  40 7c fb c0 78 70 75 09  fa bc ec 7b ea 44 7c 00   @ ..xpu.... .D . 
000000b0  00 e8 83 00 69 73 6f 6c  69 6e 75 78 2e 62 69 6e   ....isolinux.bin 
000000c0  20 6d 69 73 73 69 6e 67  20 6f 72 20 63 6f 72 72    missing or corr 
000000d0  75 70 74 2e 0d 0a 66 60  66 31 d2 66 03 06 f8 7b   upt...f f1.f... 
000000e0  66 13 16 fc 7b 66 52 66  50 06 53 6a 01 6a 10 89   f... fRfP.Sj.j.. 
000000f0  e6 66 f7 36 e8 7b c0 e4  06 88 e1 88 c5 92 f6 36   .f.6. .........6 
00000100  ee 7b 88 c6 08 e1 41 b8  01 02 8a 16 f2 7b cd 13   . ....A...... .. 
00000110  8d 64 10 66 61 c3 e8 1e  00 4f 70 65 72 61 74 69   .d.fa....Operati 
00000120  6e 67 20 73 79 73 74 65  6d 20 6c 6f 61 64 20 65   ng system load e 
00000130  72 72 6f 72 2e 0d 0a 5e  ac b4 0e 8a 3e 62 04 b3   rror...^....>b.. 
00000140  07 cd 10 3c 0a 75 f1 cd  18 f4 eb fd 00 00 00 00   ...<.u.......... 
00000150  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................ 
This is the boot sector. One of the fun things about ISO9660 is that it doesn't have a boot sector in the usual x86 sense - firmwares are expected to read enough of the filesystem that they can find the bootloader in it and run it directly. x86 isn't really smart enough to manage that, so it uses something called El Torito[2]. In any case, this is usually empty space on an x86 CD. But with an increasing number of systems shipping without optical drives, real CD installs are decreasing in popularity. We use a piece of software called isohybrid that allows the building of ISO9660 images that can be written directly onto a USB stick. Asking a machine to boot off them will execute the boot sector located here, which then loads a real bootloader that's capable of reading ISO and booting the OS. It'll just be ignored when it's on a real CD.

There's one difference here, though. The isohybrid bootsector has been modified so that the first 32 bytes are just noops, and this has been inserted:
00000000  45 52 08 00 00 00 90 90  00 00 00 00 00 00 00 00   ER.............. 
45 52 ("ER") indicates the presence of an Apple partition map. This will become important later. 0800 indicates that it's using 2048-byte sectors. The 9090 is a lie to convince the firmware that it's not a zero-sized disk without representing dangerous code. We need an Apple partition map because some older Macs won't boot off CD unless the CD has one. But it's sitting right at the start of the boot sector, and this code is going to be executed. Thankfully, the entire Apple header decodes to
00000000  45                inc bp
00000001  52                push dx
00000002  0800              or [bx+si],al
00000004  0000              add [bx+si],al
00000006  90                nop
00000007  90                nop
00000008  0000              add [bx+si],al
0000000A  0000              add [bx+si],al
0000000C  0000              add [bx+si],al
0000000E  0000              add [bx+si],al
00000010  0000              add [bx+si],al
00000012  0000              add [bx+si],al
00000014  0000              add [bx+si],al
00000016  0000              add [bx+si],al
00000018  0000              add [bx+si],al
0000001A  0000              add [bx+si],al
0000001C  0000              add [bx+si],al
0000001E  0000              add [bx+si],al
which is completely harmless - we can execute all these instructions without any interesting changes in state. They'll all be undone by the rest of the boot sector.
000001b0  14 05 00 00 00 00 00 00  4c 1e ed 76 00 00 80 00   ........L..v.... 
000001c0  01 00 00 3f a0 89 00 00  00 00 00 50 14 00 00 fe   ...?.......P.... 
000001d0  ff ff ef fe ff ff a4 00  00 00 70 04 00 00 00 fe   ..........p..... 
000001e0  ff ff 00 fe ff ff 44 05  00 00 c0 08 00 00 00 00   ......D......... 
000001f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 55 aa   ..............U. 
This is the MBR partition table. The aim here was to produce media that would boot via BIOS just as well as it does via EFI, and it turns out that there are some systems that refuse to BIOS-boot off GPT media. So we need an MBR partition map. The first entry covers the entire disk and is of type 0. This is important, because some EFI implementations are strict about MBR parsing - if there's an MBR with overlapping partitions, the entire MBR will be ignored. Inconvenient. Fortunately, we've got the source code to this code, and it turns out that partitions of type 0 are ignored when performing this check. So, there's a partition of type 0.

Why does it cover the entire disk? Once we've booted the OS, we need to be able to read the ISO image contained on the USB stick. That means the kernel needs to be able to mount it, which means we need a partition entry that covers the entire disk. Linux is perfectly happy mounting a filesystem from a partition of type 0.

So, the next partition. This is an EFI boot partition that points at the embedded VFAT El-Torito image. Some firmware will decide that we've got an MBR and so will only boot off a partition that exists in it. So, here's an MBR partition to keep them happy.

The final partition covers the embedded HFS+ image. It's there purely for convenience - it means we can access it under Linux in order to update its contents for testing purposes.
00000200  45 46 49 20 50 41 52 54  00 00 01 00 5c 00 00 00   EFI PART....\... 
00000210  09 27 93 7e 00 00 00 00  01 00 00 00 00 00 00 00   .'.~............ 
00000220  fe 4f 14 00 00 00 00 00  30 00 00 00 00 00 00 00   .O......0....... 
00000230  de 4f 14 00 00 00 00 00  2a 26 0f 37 23 c9 7f 4f   .O......*&.7#..O 
00000240  90 df 5e fe 0a 60 1c b0  10 00 00 00 00 00 00 00   ..^.. .......... 
00000250  80 00 00 00 80 00 00 00  ec 70 63 c1 00 00 00 00   .........pc..... 
00000260  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................ 
And here we have the GPT header. Nothing complicated here, other than it indicates that the first partition descriptor is at LBA 0x10, ie byte 0x2000 - that's further into the disk than normal. That leaves us enough space to fit the Apple partition entries.

Why have a GPT at all? The EFI spec says that machines should boot fine from an MBR partition. Sadly, not all seem to. It also lets us represent the HFS+ partition in a way that makes the Mac firmware happy.
00000800  50 4d 00 00 00 00 00 03  00 00 00 01 00 00 00 10   PM.............. 
00000810  41 70 70 6c 65 00 00 00  00 00 00 00 00 00 00 00   Apple........... 
00000820  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................ 
00000830  41 70 70 6c 65 5f 70 61  72 74 69 74 69 6f 6e 5f   Apple_partition_ 
00000840  6d 61 70 00 00 00 00 00  00 00 00 00 00 00 00 00   map............. 
00000850  00 00 00 00 00 00 00 0a  00 00 00 03 00 00 00 00   ................ 
00000860  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................ 
2K into the disk, here's an Apple partition map. It's 2K into the disk because we set the sector size to 2K in the partition map header. Why did we do that? Because the default is 512 bytes, and if we'd put the partition map at 512 bytes it would have been on top of the GPT header. Why 2K rather than 1K? A couple of reasons. First, the Apple partition map is only used when we boot off an actual CD, and the CD sector size is genuinely 2K. Secondly, because CDs have a sector size of 2K, 2K is a value that's actually been tested in the real world. It's nice to avoid tempting fate.
00001000  50 4d 00 00 00 00 00 03  00 00 00 29 00 00 04 70   PM.........)...p 
00001010  45 46 49 00 00 00 00 00  00 00 00 00 00 00 00 00   EFI............. 
00001020  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................ 
00001030  41 70 70 6c 65 5f 48 46  53 00 00 00 00 00 00 00   Apple_HFS....... 
00001040  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................ 
00001050  00 00 00 00 00 00 04 70  00 00 00 33 00 00 00 00   .......p...3.... 
00001060  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................ 
*
00001800  50 4d 00 00 00 00 00 03  00 00 01 51 00 00 08 c0   PM.........Q.... 
00001810  45 46 49 00 00 00 00 00  00 00 00 00 00 00 00 00   EFI............. 
00001820  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................ 
00001830  41 70 70 6c 65 5f 48 46  53 00 00 00 00 00 00 00   Apple_HFS....... 
00001840  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................ 
00001850  00 00 00 00 00 00 08 c0  00 00 00 33 00 00 00 00   ...........3.... 
00001860  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................ 
The Apple partition map entries. One partition covers the entire disk, the other the embedded HFS+ filesystem. Why do this? Because not all Macs understand EFI El Torito, so won't EFI boot a CD unless there's an Apple partition map. Why have an HFS+ partition at all? Because the same Macs won't boot off FAT.
00002000  a2 a0 d0 eb e5 b9 33 44  87 c0 68 b6 b7 26 99 c7   ......3D..h..&.. 
00002010  d0 84 a5 d4 aa 89 e0 40  81 f9 fc e4 04 e9 c2 99   .......@........ 
00002020  00 00 00 00 00 00 00 00  10 4b 14 00 00 00 00 00   .........K...... 
00002030  00 00 00 00 00 00 00 00  49 53 4f 48 79 62 72 69   ........ISOHybri 
00002040  64 20 49 53 4f 00 49 53  4f 48 79 62 72 69 64 00   d ISO.ISOHybrid. 
00002050  41 70 70 6c 00 00 00 00  00 00 00 00 00 00 00 00   Appl............ 
00002060  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................ 
*
00002080  a2 a0 d0 eb e5 b9 33 44  87 c0 68 b6 b7 26 99 c7   ......3D..h..&.. 
00002090  68 d5 e0 27 72 83 c6 4c  a7 ae 92 dd ed 6c 89 71   h..'r..L.....l.q 
000020a0  a4 00 00 00 00 00 00 00  13 05 00 00 00 00 00 00   ................ 
000020b0  00 00 00 00 00 00 00 00  49 53 4f 48 79 62 72 69   ........ISOHybri 
000020c0  64 00 41 70 70 6c 65 00  41 70 70 6c 00 00 00 00   d.Apple.Appl.... 
000020d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................ 
*
00002100  00 53 46 48 00 00 aa 11  aa 11 00 30 65 43 ec ac   .SFH.......0eC.. 
00002110  68 d5 e0 27 72 83 c6 4c  a7 ae 92 dd ed 6c 89 71   h..'r..L.....l.q 
00002120  44 05 00 00 00 00 00 00  03 0e 00 00 00 00 00 00   D............... 
00002130  00 00 00 00 00 00 00 00  49 53 4f 48 79 62 72 69   ........ISOHybri 
00002140  64 00 41 70 70 6c 65 00  41 70 70 6c 00 00 00 00   d.Apple.Appl.... 
00002150  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................ 
Three GPT entries - one covers the entire CD, one covers the embedded FAT filesystem, one covers the embedded EFI filesystem. That ensures that they're all accessible to the firmware.
00008000  01 43 44 30 30 31 01 00  4c 49 4e 55 58 20 20 20   .CD001..LINUX    
00008010  20 20 20 20 20 20 20 20  20 20 20 20 20 20 20 20                    
00008020  20 20 20 20 20 20 20 20  46 65 64 6f 72 61 2d 4c           Fedora-L 
00008030  69 76 65 43 44 20 20 20  20 20 20 20 20 20 20 20   iveCD            
00008040  20 20 20 20 20 20 20 20  00 00 00 00 00 00 00 00           ........ 
00008050  c4 12 05 00 00 05 12 c4  00 00 00 00 00 00 00 00   ................ 
00008060  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................ 
00008070  00 00 00 00 00 00 00 00  01 00 00 01 01 00 00 01   ................ 
00008080  00 08 08 00 40 00 00 00  00 00 00 40 15 00 00 00   ....@......@.... 
00008090  00 00 00 00 00 00 00 17  00 00 00 00 22 00 1d 00   ............"... 
000080a0  00 00 00 00 00 1d 00 08  00 00 00 00 08 00 70 05   ..............p. 
000080b0  01 09 30 36 f0 02 00 00  01 00 00 01 01 00 20 20   ..06..........   
000080c0  20 20 20 20 20 20 20 20  20 20 20 20 20 20 20 20                    
The ISO9660 superblock. This is completely standard. From here on there's nothing terribly surprising - the CD filesystem itself is entirely normal. The only slight oddity is that we have three embedded El Torito images. The first of these is a BIOS-bootable disk image. That'll be executed whenever the CD is put in a non-EFI machine. The second is a VFAT EFI boot image. That's used for the majority of EFI systems. The third is an HFS+ EFI boot image. There's no strict requirement for the HFS+ one to be an El Torito image - CD booting on Macs is already handled by the Apple partition map. Storing it as an El Torito is purely for convenience, since it guarantees correct alignment and avoids us having to parse the entire ISO9660 image to find its location when generating the partition maps.

In summary: Three partition maps, three bootable images, support for BIOS, UEFI and Mac platforms, works whether it's burned to a CD or written directly to a USB stick. I'm pretty pleased with that.

[1] Other than an awkward bug where something goes horribly wrong during Radeon graphics init, so Radeon-based Macs aren't working too well at the moment. We're working on it.

[2] The world decided that writing a real ISO9660 driver for BIOS was hard, so came up with El Torito. El Torito is a spec for embedding disk images inside ISO9660. There's a pointer to the disk image in the Cd header, so the BIOS simply reads a few blocks off CD, finds that pointer and then sets up a bunch of disk i/o interrupts to point at the embedded filesystem rather than a real disk. From that point on, the El Torito image simply behaves like a floppy or hard drive. This was a reasonable compromise given how resource limited older BIOS implementations were.

For reasons that aren't entirely clear, UEFI doesn't mandate that implementations support ISO9660. So even though our firmware is now sufficiently capable that the only thing standing between it and emacs is someone being sufficiently bored, we still use El Torito. Fortunately the spec allows multiple El Torito images to be embedded, so we can include one that's bootable by BIOS systems and another that's bootable by UEFI systems.

comment count unavailable comments

30 April 2012

Cyril Brulebois: Debian XSF News #11

Long time no see Summary Anyway, here are some quick news from the X packaging front, focussing on the past few weeks.
  1. While I was busy doing other things, Julien took care of uploading lots of libraries (making most of them multiarch-aware) along with our usual meta-packages (like x11-apps, x11-utils, etc.), preparing for the upcoming 7.7 katamari.
  2. Mesa 8.0.2 was finally uploaded to experimental, where it seems to be building fine, and working fine, at least for me.
  3. Accordingly, I m planning an upload to unstable very soon, and I won t be disabling wayland support this time, since wayland/weston reached their first milestone with a public release (0.85). There s nothing very interesting to see here, but since wayland support doesn t really hurt, I thought I d just keep it. That s why wayland hit unstable yesterday; weston should follow after mesa. (In case somebody is in a hurry, they have been in experimental for quite some time already.)
  4. Scrolling issues with the synaptics driver seem to be finally fixed thanks to rc4: #665004 was confirmed as fixed by many reporters (thanks everyone for the quick feedback after my ping). Accordingly, I ve pinged the release team to get an age-days 3 to make it migrate faster, and a kind RM added that hint to his file, so testing is getting the fixed package thanks to this midnight s britney run.
  5. libcairo2/server/EXA/ati/nouveau fun: will be added through an edition of this post. Executive summary: downgrade libcairo2 to testing s version if you re seeing text corruptions.
Upcoming X server transition X server 1.12 has been prepared in experimental for a while, from release candidates to the first stable release from server-1.12-branch. Since a bunch of drivers were uploaded to cope with that version when it shows up, we should be able to upload xorg-server 1.12 to unstable VERY SOON. What does that mean? Basically, that s a transition. In details:
  1. We upload xorg-server, and wait for it to be built everywhere, then we trigger binNMUs for all architectures at once when it s ready on all of them.
  2. Unlike shared libraries, there s no old and new library packages (old+new SONAME); instead, the server itself provides different packages (because of the different input and video ABI). That means that drivers won t be installable until they are rebuilt against the new server. Usually, we re talking about a few dinstall runs, meaning less than a day.
Frequently Yelled Phrases:
  1. Upgrades are broken! No, it just means you can t upgrade the server alone, you need the drivers too (see above).
  2. Installations are broken! Well, that s unstable, and you probably know installability-related issues are trivially solved by pulling packages from testing when needed. This is such a case.
Please don t report bugs on this topic, thanks already, and enjoy that new server.

John Goerzen: Review: Amateur Radio Handhelds (HTs), APRS, and Battery Tuning Tips

There are a lot of opinions about handhelds for amateur radio users (these handhelds are often known as HTs). I ve used three of them, two with APRS capability, and thought it s about time I write about them. First, I ll talk about the units in particular, then I ll get to some broader Yaesu vs. Kenwood generalizations and conclusions. Yaesu VX-7R a rugged first HT without APRS Cost: $350 as of 4/30/2012 This was the first HT I got as a ham, at the suggestion of Mike AE0MW. It truly does make a great first handheld for a ham. Radio-wise, one unique feature is a receive that s wideband enough to cover both broadcast FM and broadcast AM, the various ham bands, and plenty of others besides. The battery life quoted in the manual is 6 hours on 2m and 5.5 hours on 440 (using standard 6s TX / 6s RX / 48s squelched metric), and in my experience it seems it must be even better in some cases. The real piece of news about this unit, though, is just how rugged it is. It says submersible across the front and I absolutely believe it. I have personal experience with its ruggedness. I once was at an event and put the radio on my car roof while helping one of my children into the car. I then started driving home and forgot it there. When we got home, I realized what had happened, and also realized what that mysterious CLUNK along the busy county road was. So I drove 45 minutes back to where I heard the clunk, and found the VX-7R still lying in the roadway, where it had been for 1.5 hours on the 55 MPH road. The thing was really beat up. It had obviously been hit by numerous vehicles. The antenna was ripped off, taking the SMA mount with it. But wouldn t you know it, the darn thing still powered up. I took it to a local amateur radio shop, and about $80 later it was repaired. Incredible. The only real problem was the antenna connector. I took this radio with me on my bicycle many days, mounted on my handlebars. It got bounced around, but still worked great. Some days I listened to FM radio from it while riding my bike, monitoring a local repeater while I rode. Other days, I spent most of my ride (about an hour each way) chatting with people on the repeaters I have a mobile antenna mounted on the bike, fed to the VX-7R, and a headset. It all worked fine never a problem at all. The ruggedness has its downside. All of the connectors on the radio, except for DC in, are screw-down even the speaker/mic connector. This obviously helps keep water out, but means that it can take a lot longer than normal to do a simple thing like plug in a speaker/mic. It doesn t need any tools, but can get a little annoying. The radio physically is small (unless you install the belt clip, which has an odd peg-based mechanism that protrudes unnecessarily far and is surprisingly non-rugged). It can easily fit into a pocket. The other downsides of the VX-7R mostly surround its interface. I m not one of the Yaesu haters that seem to be so common. I find the interface usable if you read the manual; it seems a lot of people that complain about it don t. But it is quirky. The SET mode is one long menu in sort of a ring. You scroll with the knob, and when you get to the end, it repeats to the beginning. There are one or two shortcut keys to a specific setting, but overall either you use the thing so much you know exactly where you re going, or you re twisting the knob for awhile until the option you want rolls around. (I know of nobody that uses it so much they know exactly where they re going.) They do have options grouped into categories, but it doesn t help much because there s no quick way to skip between categories. The dual transceivers work less elegantly than on the TH-D72A or VX-8GR. Instead of being two equal transceivers A and B, they are main and sub . The sub transceiver is not broadband receive like the main receiver is. But there are also other limitations that have no apparent logic. For instance, you can program memory groups into the device putting, say, all the local repeaters into a certain group, or all the public safety frequencies (to use as a scanner). You can go to the special set menu, select group, then activate SCAN, and it will scan only the memories in that group. But you can t select the special group mode on the sub transceiver for no apparent reason. One other complaint is that the AC charger introduces so much noise to a transmission that you cannot really use the VX-7R to transmit while the charger is connected. Yaesu sells a programming cable that plugs into the speaker/mic port on one end, and a DB-9 serial port on the other, and includes programming software. For an incredibly high price. For far less, I found a similar cable on eBay that has a USB port on the other end (with a built-in USB/serial converter), and used VX-7R Commander though now that Chirp is available for Linux, I ll probably switch to it. I would probably continue to recommend this transceiver for a new ham. The ruggedness, plus the broadband RX, are features that should make it appealing. It is an excellent emergency preparedness/response radio due to those properties; having TX and RX on ham bands, plus RX on broadcast and public safety could be quite the asset. However, for someone that has any interest in APRS, one of the other two radios I mention is probably a better choice. At only $10 more, the VX-8GR sacrifices ruggedness and broadband receive for APRS functionality and could make a compelling alternative to the VX-7R at the same price point. The very low-power transmit at 50MHz and 220MHz on the VX-7R strikes me as a gimmick feature at best that has very little actual use. Shipped battery: FNB-80LI, 7.4V, 1400 mAh, lithium-ion Kenwood TH-D72A / D72E The Cadillac HT, with APRS and GPS Cost: $464 as of April 30, 2012 It s hard to use any word but incredible to describe this HT, though it does have its own rough edges. Starting with the basics, it has dual transceivers with full duplex (meaning you can be transmitting on one band while receiving on another). Its stored memory system and memory bank scanning system are both a lot easier and faster to use than Yaesu s, and work the same on both transceivers A and B, though perhaps offer slightly less flexibility than Yaesu s (on the VX-7R, a single memory can be a member of more than one group). The quoted operating time is 6 hours, which is probably accurate with APRS and GPS off, matching (or nearly matching) the VX-7R. The TH-D72A has the usual mic and speaker ports. Unlike Yaesu, Kenwood has used the same jack for years, so it is not necessary to purchase new accessories with each upgrade. The unit also has both serial (Kenwood connector) and standard mini USB ports, and even ships with a USB cable. The USB port is designed to interface to a PC, and the radio presents itself as a serial-over-USB device. Kenwood also includes MCP-4A, the programming software for the unit, free. This is one example of several things that Kenwood includes for free but are costly add-ons with Yaesu. Kenwood s configuration menu system is hierarchical. You can scroll through the four top-level menus (RADIO, GPS, APRS, and SKY), then navigate through sub menus. The result is that it s both faster and easier to find what you want than on the Yaesu menus. Plus, as you navigate, the radio shows you the shortcut key to get to a particular option (each level of menu is numbered starting) so, for instance, Menu-1-1-0 takes me directly to the configuration for RX battery saver interval far faster than I could get there on the VX-7R or VX-8GR. Only the APRS menu gets a bit crowded with this setup. The D72A supports Kenwood s Sky Command II an intriguing way of making it essentially a remote for a Kenwood HF rig such as the TS-2000. It works by engaging a crossband repeater for the audio, and setting up a AX.25 packet link for the control. It works, but as the response time to frequency adjustments is measured in seconds, is klunky for tuning around a HF band. A nifty, though perhaps not supremely useful, feature with some hackable potential that I haven t explored yet. The TH-D72A is one of only two shipping general-purpose amateur radios that have a built-in GPS the other is the Yaesu VX-8GR, which I ll review below. The GPS works well, and can get a fix indoors if desired. It has a system of saving waypoints, which you can then navigate back to later (using distance/bearing indicators). It also has a track log. While the track log can t be viewed on the unit, it can be downloaded with the included MCP-4A software and saved in a variety of formats including Google s KML for later importing into Google Maps or Google Earth. I enjoy this feature on trips to see where I went later on. There is also a GPS-only mode, which disables all of the other radio circuitry on the radio for very low power consumption. The GPS navigation screens all support heading-up or north-up indicators. But where this radio really shines is APRS. The D72 has all the basics you d expect sending and receiving beacons, sending and receiving messages and bulletins, etc. It has built-in support for being a digipeater in many different ways, including new-N UI-Trace. Coupled with an MFJ VHF amplifier, this could make a nice temporary (or even permanent) digi. The message interface permits sending, receiving, and shortcuts for replying to messages. Beacon transmission can be completely manual, at set intervals, or using SmartBeaconing. Outbound beacons also support proportional pathing (meaning adjusting via-path to not have wide coverage with every transmission). Also, if not using SmartBeaconing, a decay algorithm can be used to send beacons less frequently when the station s location isn t changing. An alternative tells the system to transmit a beacon every time PTT is released, subject to rate limiting by interval. So lots of choices there. For incoming beacons, there are various filters by callsign pattern, packet type, etc. that control whether they will be processed at all, and what kind of alert (visual or audible) to present. Beacons are also placed in a received beacon list, sorted with the most recent at the top (duplicates from the same station are always removed, so only the most recent is presented.) A long press of the LIST button shows time received and type of device next to the callsign. Selecting a specific beacon shows status text, comment, device type, bearing/distance (with graphical north-up or heading-up display), telemetry (weather information and the like), and a little bit of info about the via-path. Pretty nice to see weather reports from local weather stations on there. You can sort the list by received time, station call, or distance from your position but it doesn t stay sorted by anything other than received time, and takes several seconds to re-sort. Seems like a bit of an oversight there. The D72A supports QSY information in beacons. This can automatically insert the frequency of the other band on the transceiver into your transmitted beacons for you, or give you a quick way to tune to the frequency mentioned on others beacons. Either way, a nice touch. The D72 also supports query packets, such as packets asking your station to transmit its position right now. The TH-D72A can directly interface with several types of weather stations via serial link to read weather sensor information and transmit it into APRS packets directly, with no need for a PC to be in the picture at all. But if you do hook up a PC to it, there are quite a few more possibilities. You can hook it up to PC APRS software (or a hardware device such as the AVMAP) to see locations of other APRS stations on a map. It can emit APRS packets, plus even GPS sentences, down the USB port to the PC. Moreover, in PACKET mode, it acts as a full TNC, with a fairly robust TNC command set. In short, it can do more than APRS; it can also do regular AX.25 such as DX clusters, BBS, nodes, etc. As far as I know, this is the only HT that can interface with a PC in this manner, and only Kenwood s mobile D710 has the same kind of feature set at that. Kenwood includes a lot of documentation with the TH-D72A. The 51-page printed manual is a summary or introductory guide. The included CD-ROM supplies another 75 pages of detailed reference material, and the 92-page in-depth APRS manual has a level of detail that true geeks like me appreciate. I ve referred to Kenwood s documentation more than once while figuring out things about the VX-8GR (which woefully under-documents things like SmartBeaconing). That said, it appears that at least some of the documentation has been copied from the earlier TH-D7A. Page 4 of the printed book is a good example. It talks about the memory effect of the battery, and warns against unplugging and replugging the charger because the charge cycle will be reset and the battery will be over-charged (I find it hard to believe that a Li-Ion charge controller would be that stupid, and furthermore direct observation suggests that it isn t.) Parts of the in-depth APRS guide appear to have been written for the D710, but that s a really minor nit. Unlike Yaesu, Kenwood issues periodic firmware updates to the D72A, which you can apply over USB. They have fixed bugs and added features to the unit over time. Now onto the things that aren t so good about the D72A. I ll start with the battery system, since we were already discussing it. Despite shipping with a much larger battery than the VX-8GR (1800 mAh vs. 1100 mAh), it only manages roughly equal battery life with APRS and GPS engaged. (It will probably do better as a simple voice unit, however.) This has been confirmed by numerous reports on the Internet. I will discuss this topic more below. There is very little else to fault the D72A on, feature-wise. I have a minor nit in that it is impossible to cause the keylock feature to also lock PTT. It would be nice to be able to see raw APRS packets on beacons and messages. Other than that, I can t think of a feature it really lacks. Compared to the VX-7R and VX-8GR, the TH-D72A is significantly larger physically, in every dimension. It is not uncomfortably large, and still fits in my hand fine. But its size is enough different that it feels like the design is dated and could have been more compact if Kenwood would have bothered. It s a nit, sure, but a nontrivial one. With the single exception of the sturdy metal belt clip, the D72 doesn t feel nearly as rugged as the VX-7R, and not even as rugged as the VX-8GR. The keys have a squishy feel to them, the PTT button works fine but has a cheap plastic design (as opposed to the rubberized versions on Yaesu s HTs). The manual doesn t mention it, but one Kenwood brochure mentions and IP54 weatherproofing. That means it is protected against limited ingress of dust and against water sprayed from all directions limited ingress permitted. Contrast that to the VX-7R, which is rated for 30 minutes of submersion at 3ft and has a magnesium case. It seems to be specced similarly to the VX-8GR, though the VX-8GR certainly feels a lot more solid. I have no proof, as I m not about to sacrifice my HTs for science, but I doubt that the TH-D72A would have survived over an hour on a busy road as well as the VX-7R did, and probably not even as well as the VX-8GR would. The case is plastic a stout plastic, but still plastic. Like the VX-8GR, and unlike the VX-7R, the D72A does not have broadband receive. It can receive some bands adjacent to the ham bands it supports, which includes a lot of bands of interest to people with scanners, but still can t receive broadcast FM signals like the VX-7R. Shipped battery: PB-45L, 1800 mAh, lithium-ion Yaesu VX-8GR: Cheaper APRS & GPS Cost: $360 as of 4/30/2012 One could probably call this Yaesu s closest competitor to the D72A. At about $100 cheaper, it doesn t have a featureset that matches Kenwood s, but it does have a few innovations that the D72A lacks. Starting with the basics, it lacks the VX-7R s broadband receive, with the receive roughly matching the TH-D72A s. The 8GR is a dual-transceiver HT, and it works this effectively (moreso than the VX-7R). Yaesu has a bad habit of changing connectors on radios with regularity, and charging an arm and a leg for accessories to boot. Even within the VX-8 line, the 8GR uses different accessories than the 8DR, and of course has different plugs than the 7R (though it appears that the DC power plug is the same, and with some luck you might be able to use a VX-7R speaker/mic on the 8GR, though not the reverse). The menu system on the 8GR is still similar to the 7R, though Yaesu has done several things to improve it. For one, scrolling through the menu now shows several lines of context on the screen at once, making it faster to scan. Also, there are more ways to jump into the menu at a certain location than before and even a small bit of clumsily-implemented hierarchy (there are several settings on the SmartBeaconing page, for instance). The menu key now toggles between various displays: the default frequency/status display, a GPS display, an APRS staion list, and an APRS message list. Just about everything operationally takes more keypresses than the D72A. On the D72A, it s one or two keys (a physical button or F+button) to do almost everything: toggle GPS state, change TNC/APRS state (turn on or off), etc. All of that is in the scrolling menus on the 8GR. The quickest way there, which is documented in the manual, is to press MENU until a certain screen comes up, then press and hold MENU to bring up the settings (defaulting to a certain APRS-related category), then scroll and change settings. It s a pain to turn APRS on and off, because you have to do this process for both the GPS and the APRS modem. Inexplicably, there is a hotkey to change the APRS beacon method (manual, auto, or SmartBeaconing) but not to turn APRS itself on or off. (The D72A has a hotkey to toggle the beaconing, though not to change its method; though in truth, if you do it frequently, the menu shortcuts will get you there rapidly.) Physically, the VX-8GR is closer to the size of the 7R than the size of the D72A, and notably is significantly smaller than the D72A (at least with the standard battery). As noted in the D72A review, the VX-8GR feels more rugged than the D72A, though whether that is actually true or not is hard to pin down. It is definitely less rugged than the VX-7R. The keys require more pressure than the D72A, and in this they are similar to the 7R, but feel satisfyingly solid. Unlike the other radios here, the 8GR does not have a dedicated volume knob, having only one dial on the top. To adjust volume, you hold the volume button on the left while twisting the knob. In practice, this is probably not usually very annoying, but if the radio is on your belt or otherwise not in your hand, this would be a frustration. (I think it would be particularly annoying if using it with a speaker/mic). Setting 99 will let you change the key so you don t have to hold it in, which could probably go a long way to making the situation more tolerable. One unique feature of the VX-8GR, as far as I know completely unique to it, is a vibrating alert. This would most frequently be used with APRS to provide a nearly-silent alert of incoming messages and the like. The screen of the 8G, while similar in size to both the D72A and the 7R, appears to be higher-resolution (or if not, they make better use of it). More information is packed onto the screen at once, and although the D72A does have a small font, it uses it so rarely that lots of scrolling is needed. The 8GR uses a smaller font than the D72A to show content of messages and the like, which makes a much faster experience since there is a lot less scrolling. Neither radio has a setting to change this behavior, so if your eyesight isn t good, you may prefer the D72A anyhow. The VX-8GR supports a heading-up or a north-up view of the received GPS data, but strangely it does not support this when navigating to a received beacon (north-up is the only option). Unlike the TH-D72A, you can engage keylock on the 8GR while someone s beacon is on the display. Also unlike the TH-D72A, you can lock out the PTT key on the 8GR. However, the keylock feature is just a quick press of the power button, which makes me a bit nervous. And worse, if you tell it to lock the PTT key, then it also won t transmit any automatic APRS beacons! There are a lot of things the D72A supports in the APRS area that the 8GR doesn t. Here s a summary of features missing in the 8GR compared to the D72A: voice alert (can t even do it manually since tone/CTCSS are locked out in APRS mode), quick replying to messages, TNC mode (meaning you can t use it with PC-based APRS programs), full AX.25 packet mode, full PC linking, weather station inputs, built-in digipeater mode, heading-up display, GPS track logs, QSY in beacons, quick tuning to others QSY info, responding to position queries, proportional pathing, automatic decay, beaconing on PTT release, sorting of beacon list, hotkey access to many features, and I m sure the list goes on. On the flipside, the only thing feature-wise that you get on the 8GR s APRS implementation that the D72A lacks is ability to inspect raw APRS packets. The VX-8GR has the lowest-capacity battery of the three radios covered in this post, and this is an oft-cited problem for users of the unit. Yeasu does seem to do a much better job of power management than Kenwood, though, so in full APRS and GPS mode, the battery life is roughly the same, amazingly enough. It is unlikely that the talk time on the 8GR would match either the 7R or the D72A, however. Kenwood and Yaesu both have a battery saver feature which cuts power to the RX circuit except for brief checks for signals. Yaesu completely disables this while the APRS modem is on (and STILL matches Kenwood s battery life, despite the smaller battery!) Kenwood doesn t, though recommends changing the signal-check interval from 0.2s to 0.03s in order to avoid truncating APRS packets. Yaesu offers an 1800 mAh extended-life battery which should significantly exceed Kenwood s battery life. Aftermarket vendors have 2000 mAh batteries as well. Either way, expect APRS to be a drain on batteries. More on that below. Although Yaesu includes 168 pages of documentation with the 8GR, don t expect it to match the quality and detail of Kenwood s 218 pages. There are a lot of gimmicky/useless features on the 8GR (WIRES, for one) that get extensive treatment, and there is a fair bit of repetition. I particularly single out the SmartBeaconing documentation on the 8GR as being, at best, woefully incomplete and probably also inaccurate to boot. Read the D72A manuals to figure out how that feature works on your 8GR. I bought the VX-8GR intending it to be something akin to a more versatile TinyTrak. On that score, it mostly succeeds. It may be my go-to rig for use at bicycle rides, marathons, emergencies, etc., while the D72A will probably be the one that goes with me on trips. Shipped battery: FNB-101LI, 7.4V, 1100 mAh, lithium-ion Not covered: VX-8DR poor value for the dollar Cost: $434 ($550 with GPS and GPS connector) Yaesu s top-of-the-line HT is sometimes considered to be the VX-8DR. It maintains the broadband capability of the 7R, is probably almost as rugged as the 7R, and has APRS built in, like the 8GR. It even has an option to add a Bluetooth board. What is doesn t have built-in is a GPS. You can add one on for $77 for the FGPS-2 plus $39 for the CT-136 connector which connects the GPS to the unit. But then you have a unit a lot less rugged than even the D72A (that s a small connector for the GPS), a lot less small, with the same APRS featureset as the 8GR (meaning a lot less than the D72A), which costs about $100 more than the D72A. Frankly I think this makes for a poor APRS package, and would probably only be reasonable for someone that wants other 8DR features and has a desire for some very occasionaly APRS work. Battery Life and APRS One of my first surprises with APRS HTs was the poor battery life I saw. Doing my research seemed to suggest that, contrary to popular opinion, the transmitted beacons were not the culiprit, but the receive circuits were to blame. Because it is not acceptable to cut off the first 200ms of an AX.25 packet like it is with a repeater, the RX circuit is either engaged much more frequently (Kenwood) or continuously (Yaesu), putting a lot more drain on the battery. (This has also been confirmed by multiple others that have done testing) The GPS receiver also adds drain, and on the D72A, so does the TNC, which is always active when APRS is. If you don t care about received beacons, you can dramatically raise the battery life on the D72A by setting the power saver to 1 second or greater as high as 14 hours by one report. On either unit, raising the squelch should have some effect (though not as much; but in any case, weak packets won t decode anyhow, so there s no sense in letting them in.) On the 8GR, getting the extended life 1800 mAh (or aftermarket version) could produce battery life in nearly that same region, without compromising on the RX side of things. Conclusions If you want a HT capable of APRS, seriously think of the TH-D72A before anything else. It is $100 more expensive than the 8GR, but has more than $100 worth of extra features (and included things, like PC link cable and software, that are extra on the 8GR), so it has a better value. If you re particularly budget-conscious or want the most ruggedness you can find, the 7R and 8GR are solid contenders if you can sacrifice the extra APRS features. Update May 1: Clarified what the lack of TNC mode on the VX-8GR means, and also how the VX-8GR PTT keylock also locks out APRS transmissions.

29 April 2012

Peter Eisentraut: Setting the time zone on remote SSH hosts

The tasks: I have one or more desktop/laptop machines with varying local time zones (because the persons using them are actually in different time zones, or because the one person using them travels). I also have a number of servers configured in some random time zones. (It could be the time zone where they are physically located, or the time zone of the person who installed it, or UTC for neutrality.) Now what I would like to have happen is that if I log in using SSH from a desktop to a server, I see time on that server in my local time zone. For things like ls -l, for example. Obviously, this illusion will never be perfect. Nothing (except something very complicated) will adjust the time stamps in the syslog output, for example. But the ls -l case in particular seems to come up a lot, to check how long ago was this file modified. This should be completely doable in principle, because you can set the TZ environment variable to any time zone you like, and it will be used for things like ls -l. But how do you get the TZ setting from here to there? First, you have to make the remote SSH server accept the TZenvironment variable. At least on Debian, this is not done by default. So make a setting like this in /etc/ssh/sshd_config:
# Allow client to pass locale environment variables
AcceptEnv LANG LC_* TZ
You also need to make the equivalent setting on the client side, either in /etc/ssh/ssh_config or in ~/.ssh/config:
SendEnv LANG LC_* TZ
Which leaves the question, how do you get your local time zone into the TZ variable to pass to the remote server? The actual time zone configuration is the file /etc/localtime, which belongs to glibc. In current Debian, this is (normally) a copy of some file under /usr/share/zoneinfo/. In the distant past, it was a symlink, which would have made things easier, but now it's a copy, so you don't know where it came from. But the name of the time zone is also written to /etc/timezone, so you can use that. The format of the TZ environment variable can be found in the glibc documentation. If you skip past most of the text, you will see the relevant parts:
The third format looks like this: :CHARACTERS Each operating system interprets this format differently; in the GNU C library, CHARACTERS is the name of a file which describes the time zone.
So what you could do is set
TZ=":$(cat /etc/timezone)"
Better yet, for hopping through multiple SSH hosts in particular, make sure to preserve an already set TZ:
TZ=$ TZ:-":$(cat /etc/timezone)" 
And finally, how does one hook this into ssh? The best I could think of is a shell alias:
alias ssh='TZ=$ TZ:-":$(cat /etc/timezone)"  ssh'
Now this set up has a number of flaws, including: But it practice it has turned out to be quite useful. Comments? Improvements? Better ideas? Related thoughts:

28 April 2012

Raphael Geissert: You are doing it wrong...

... when you join a team and then every other team member stops working.

(There's a possibility that you are doing such a great job that there's no need of the others, but think about the case when your work or your way of working is killing them.)

27 April 2012

Russell Coker: BTRFS and ZFS as Layering Violations

LWN has an interesting article comparing recent developments in the Linux world to the Unix Wars that essentially killed every proprietary Unix system [1]. The article is really interesting and I recommend reading it, it s probably only available to subscribers at the moment but should be generally available in a week or so (I used my Debian access sponsored by HP to read it). A comment on that article cites my previous post about the reliability of RAID [2] and then goes on to disagree with my conclusion that using the filesystem for everything is the right thing to do. The Benefits of Layers I don t believe as strongly in the BTRFS/ZFS design as the commentator probably thinks. The current way my servers (and a huge number of other Linux systems) work of having RAID to form a reliable array of disks from a set of cheap disks for the purpose of reliability and often capacity or performance is a good thing. I have storage on top of the RAID array and can fix the RAID without bothering about the filesystem(s) and have done so in the past. I can also test the RAID array without involving any filesystem specific code. Then I have LVM running on top of the RAID array in exactly the same way that it runs on top of a single hard drive or SSD in the case of a laptop or netbook. So Linux on a laptop is much the same as Linux on a server in terms of storage once we get past the issue of whether a single disk or a RAID array is used for the LVM PV, among other things this means that the same code paths are used and I m less likely to encounter a bug when I install a new system. LVM provides multiple LVs which can be used for filesystems, swap, or anything else that uses storage. So if a filesystem gets badly corrupted I can umount it, create an LVM snapshot, and then take appropriate measures to try and fix it without interfering with other filesystems. When using layered storage I can easily add or change layers when it s appropriate. For example I have encryption on only some LVs on my laptop and netbook systems (there is no point encrypting the filesystem used for .iso files of Linux distributions) and on some servers I use RAID-0 for cached data. When using a filesystem like BTRFS or ZFS which includes subvolumes (similar in result to LVM in some cases) and internal RAID you can t separate the layers. So if something gets corrupted then you have to deal with all the complexity of BTRFS or ZFS instead of just fixing the one layer that has a problem. Update: One thing I forgot to mention when I first published this is the benefits of layering for some uncommon cases such as network devices. I can run an Ext4 filesystem over a RAID-1 array which has one device on NBD on another system. That s a bit unusual but it is apparently working well for some people. The internal RAID on ZFS and BTRFS doesn t support such things and using software RAID underneath ZFS or BTRFS loses some features. When using DRBD you might have two servers with local RAID arrays, DRBD on top of that, and then an Ext4 filesystem. As any form of RAID other than internal RAID loses reliability features for ZFS and BTRFS that means that no matter how you might implement those filesystems with DRBD it seems that you will lose somehow. It seems that neither BTRFS nor ZFS supports a disconnected RAID mode (like a Linux software RAID with a bitmap so it can resync only the parts that didn t change) so it s not possible to use BTRFS or ZFS RAID-1 with an NBD device. The only viable way of combining ZFS data integrity features with DRBD replication seems to be using a zvol for DRBD and then running Ext4 on top of that. The Benefits of Integration When RAID and the filesystem are separate things (with some added abstraction from LVM) it s difficult to optimise the filesystem for RAID performance at the best of times and impossible in many cases. When the filesystem manages RAID it can optimise it s operation to match the details of the RAID layout. I believe that in some situations ZFS will use mirroring instead of RAID-Z for small writes to reduce the load and that ZFS will combine writes into a single RAID-Z stripe (or set of contiguous RAID-Z stripes) to improve write performance. It would be possible to have a RAID driver that includes checksums for all blocks, it could then read from another device when a checksum fails and give some of the reliability features that ZFS and BTRFS offer. Then to provide all the reliability benefits of ZFS you would at least need a filesystem that stores multiple copies of the data which would of course need checksums (because the filesystem could be used on a less reliable block device) and therefore you would end up with two checksums on the same data. Note that if you want to have a RAID array with checksums on all blocks then ZFS has a volume management feature (which is well described by Mark Round) [3]. Such a zvol could be used for a block device in a virtual machine and in an ideal world it would be possible to use one as swap space. But the zvol is apparently managed with all the regular ZFS mechanisms so it s not a direct list of blocks on disk and thus can t be extracted if there is a problem with ZFS. Snapshots are an essential feature by today s standards. The ability to create lots of snapshots with low overhead is a significant feature of filesystems like BTRFS and ZFS. Now it is possible to run BTRFS or ZFS on top of a volume manager like LVM which does snapshots to cover the case of the filesystem getting corrupted. But again that would end up with two sets of overhead. The way that ZFS supports snapshots which inherit encryption keys is also interesting. Conclusion It s technically possible to implement some of the ZFS features as separate layers, such as a software RAID implementation that put checksums on all blocks. But it appears that there isn t much interest in developing such things. So while people would use it (and people are using ZFS ZVols as block devices for other filesystems as described in a comment on Mark Round s blog) it s probably not going to be implemented. Therefore we have a choice of all the complexity and features of BTRFS or ZFS, or the current RAID+LVM+Ext4 option. While the complexity of BTRFS and ZFS is a concern for me (particularly as BTRFS is new and ZFS is really complex and not well supported on Linux) it seems that there is no other option for certain types of large storage at the moment. ZFS on Linux isn t a great option for me, but for some of my clients it seems to be the only option. ZFS on Solaris would be a better option in some ways, but that s not possible when you have important Linux software that needs fast access to the storage. Related posts:
  1. Starting with BTRFS Based on my investigation of RAID reliability [1] I have...
  2. ZFS vs BTRFS on Cheap Dell Servers I previously wrote about my first experiences with BTRFS [1]....
  3. Reliability of RAID ZDNet has an insightful article by Robin Harris predicting the...

26 April 2012

Alexander Pashaliyski: Google Summer of Code 2012 Clang support for build services in Debian

This project is about extension of the Debian infrastructure with ability to build packages with clang. The key idea is to have an alternative way to build packages and easily switch between clang and gcc/g++. Clang is faster than gcc, uses less memory, and produces faster code. It is getting better with time. It is available under the BSD license. It is well documented. It can help programmers find and analyze easily their errors, because clang has much more detailed error and warning messages and it allows better diagnostics. It also provides a good alternative for programmers using gcc in the coding and compiling processes. It enforces better code quality. In the compiling process, compiler choice is usually done by setting the environment variable CC. When Makefile is generated, it contains initialization of the CC variable based on the current environment. If CC is not set, the default compiler is gcc. CC is always used by make. I proved this with tests (I set CC=/usr/bin/clang).
There must be an easy way to switch the default compiler between gcc/g++ and clang. One way would be by issuing a command like
dpkg-reconfigure default-compiler . I think that debuild, sbuild can be changed to take optional compiler argument (something like clang gcc). If this argument is not specified, the default compiler is used (according to CC)
Also I think that when the default compiler is set to clang, some special cases should be checked.
Example: There is gcc hard coded in the Makefile. In this case there should be a dialog box that offers several options to choose from:
1. Leave gcc in this line.
2. Change gcc with the CC variable.
3. Edit with the default text editor.
I have seen the 3rd option in many applications, like svn or crontab. When some file modification is required, the default editor is launched to modify the file.
Also, I ll check what are the compiling problems of the current packages that can t compile by just changing gcc with clang. This way I ll see what checks for special cases to implement.

Olly Betts: Xapian GSoC 2012 Projects

At the end of the previous episode, you may remember our gallant heroes had a pile of 30 proposals to review. We soon spotted one more to mark as invalid (just a paste with our ideas list plus a some biographical details), and another got withdrawn by the student without explanation (but was low quality anyway), so that left us with 28. We had six volunteers for mentoring, and in the initial allocation we received five student slots from Google, but we asked nicely if we could have an extra one, and were lucky enough to get it. Last year we had four students, so that's a 50% increase. Here's those 28, broken down by the project idea:
  • 8 - Weighting Schemes
  • 6 - Learning to Rank
  • 3 - Dynamic Snippets
  • 2 - Lucene Backend
  • 2 - QueryParser improvements
  • 1 - Erlang Bindings
  • 1 - Improve C# and Java bindings
  • 1 - Improve PHP Bindings
  • 1 - Improve Python Bindings
  • 1 - Improving Japanese Support
  • 1 - Node.js Bindings
  • 1 - Postlist encodings
I find it interesting that the most popular three ideas have closer connections to Information Retrieval theory than most - probably these appeal to students who have taken IR courses and already have an interest and some knowledge of the project area. I think we should aim to get more ideas like these on the list in future years. It's worth noting that in several cases students had taken an idea in sufficiently different directions that there wasn't much overlap, so we didn't just pick the best proposal for each project idea to narrow things down. Also, the proposal isn't the only factor - we like to see applicants work on patch, and to interact with us on IRC and/or email. But in the end it happens we ended up with proposals which were all from different ideas - here are those we selected:
My congratulations to the lucky six, and my commiserations to those we weren't able to select. It wasn't an easy selection to make, and we truly appreciate the time you spent writing your proposal, working on patches, and on the rest of the application process. We'd encourage you to remain involved with Xapian, and to apply to us again next year if you're still eligible for GSoC.

Paul Wise: What happens when a Debian derivative shuts down?

Over the past months we have seen the end of two Debian derivatives. In January the news came that Junta de Extremadura (Spain) were abandoning the development of LinEx and switching to Debian itself. Early in March the Debian derivatives census scripts noted that the Vanillux apt repository was down. Fabrice Quenneville then confirmed that he had to put a hold on the Vanillux project due to the cost of bandwidth and servers. In addition the future of StormOS is in doubt after Illumian was created. StormOS is a port of Debian to the OpenSolaris kernel and Illumian is similar but uses only apt/dpkg and repackages everything else. The LinEx page in the Debian derivatives census did not reveal much information about the project that would have been useful to Debian, in particular it does not list any apt repositories. As a result it is quite hard to say what has potentially been lost. Two mails from people close to or involved in the project indicate that much of the LinEx distribution was already merged into Debian. It is probably safe to say that everything of value has been merged into Debian, including at least one of the developers involved in LinEx. Vanillux was a small distribution with few developers according to the Google caches of their website. If we look at the patches created by the derivatives census scripts, we can see that the 5 source packages that were possibly derived from Debian source packages were simply imported from Christian Marillat's repository of non-free, patented, legally restricted and multimedia-related packages. The patches indicate that 3 source packages were forked from Debian and that 2 source packages were done from scratch. The forked packages seem to be mainly about enabling support for proprietary and patented codecs in several programs. This is a surprisingly small number of altered/differing packages, so what else could Vanillux folks have been working on? It appears that there were 12 new source packages that were not derived from Debian source packages. These appear to be mainly multimedia-related packages, one font imported from an Ubuntu PPA, some syslinux themes and a metapackage. The multimedia packages are all from Christian Marillat's repository. The Debian multimedia team is working hard on bringing multimedia related software to Debian and welcomes help with that. The font (Cantarell) is now in Debian under a different source package name. The metapackage appears to be very similar to from the ubuntu-meta source package from Ubuntu that uses germinate. So at first glance, the contribution of Vanillux to the world of Linux distributions appears to be in the area of artwork and package selection. The artwork produced is basically Vanillux branding and is thus not usable by Debian, although we would like more artists involved in Debian. The meta-package is not easily useful to Debian since we use a different mechanism for our task packages and our task packages have already been updated for the GNOME 3 transition. Still, the amount of difference between to source packages is relatively small. So, what else? Perusing the diff between the list of source packages exposed by the Packages and Sources files, I noted that a number of binary packages in the Packages files reference source packages not listed in the Sources files. When I saw picasa in that list, it occurred to me that Vanillux might have directly imported some binary packages without their corresponding source packages. Perusing their apt metadata confirms that they have imported some binary packages of non-free software directly from vendors. These include Google Desktop, Opera, Picasa and VirtualBox 3.2. The rest of the packages in the diff appear to be caused by some sort of issue with the import process from Debian and other apt repos. Most of the above could be achieved by adding some external commerical repositories to a normal Debian system or by merging some of those repositories (such as the Opera one) into Debian. The interesting thing about the Debian derivatives census is that it allows us to perform analyses like these and figure out what patches and packages we might like to integrate into Debian. In this way we can salvage some of the value of our derivatives if they abandon ship. If you have any ideas or code for improving the census or are running a Debian derivative, please join us at the Debian derivatives frontdesk.

25 April 2012

Vincent Bernat: XBMC Eden on Debian Wheezy

I bought some HTPC a few years ago to run XBMC, a neat media center solution. At the time, to avoid any problems, I installed it on top of a minimal Ubuntu Lucid installation with the official packages from the team XBMC. Recently, XBMC Eden has been released and XBMC has landed into Debian unstable. It was a good occasion to make the switch. Unofficial XBMC logo for Eden TL;DR: Installing XBMC on Debian Wheezy is quite easy: it almost works out of the box. The big difficulty is the configuration of the remote control: either it works as you expect or you will have to scratch your head over the pile of layers needed to work with a remote control. The configuration of my HTPC is as follows:

Installation

Installing Debian Wheezy Installing Debian Wheezy2 is pretty easy. Nowadays, getting a bootable USB key from a netinst image of Debian Installer for Wheezy is simplified:
$ sudo dd if=debian-testing-i386-netinst.iso \
>         of=/dev/disk/by-id/usb...
The installation was smooth with the exception of GRUB which was unable to install itself on the disk. This is a known bug when dealing with LVM and it comes with a simple workaround. I hope it will be corrected in time for Wheezy release. While this has little to do with the installation of XBMC, I wanted to test systemd which may become the default init in Debian (at least in Debian GNU/Linux). From README.Debian:
systemd can be installed alongside sysvinit and will not change the behaviour of the system out of the box. This is intentional. To test systemd, add init=/bin/systemd to the kernel command line and then rebooting, or install the systemd-sysv package.
The final system boots in about 15 seconds.

Configuring X Because video decoding in nouveau driver is still a work in progress, the use of the proprietary NVIDIA drivers is mandatory to be able to watch high resolution videos. Therefore, /etc/apt/sources.list should be completed with contrib and non-free repository. Then, you can install the appropriate packages: xserver-xorg-video-nvidia, nvidia-vdpau-driver and xserver-xorg. Here is my /etc/X11/xorg.conf.d/nvidia.conf:
Section "Device"
    Identifier     "NVidia ION"
    Driver         "nvidia"
    VendorName     "NVIDIA Corporation"
    Option         "HWCursor" "False"
    Option         "NoFlip" "False"
    Option         "FlatPanelProperties" "Scaling = Native"
    Option         "DynamicTwinView" "False"
    Option         "ConnectedMonitor" "DFP-1"
    Option         "CustomEDID" "DFP-1:/etc/X11/edid.bin"
    Option         "NoLogo" "True"
EndSection
Section "Extensions"
    Option "Composite" "false"
EndSection
The CustomEDID option allows the driver to get an appropriate EDID even when the AV receiver is off. You can get yours, free of charge, with get-edid from read-edid package.

Installing XBMC Thanks to the work of Andr s Mej a, XBMC is now available in Debian Wheezy. To install it, just type aptitude install xbmc. I have dropped the following xbmc.service in /etc/systemd/system directory:
[Unit]
Description = XBMC media center
After = syslog.target
[Service]
User = xbmc
Group = xbmc
Type = simple
ExecStart = /usr/bin/xinit /usr/bin/xbmc-standalone -- :0
Restart = on-failure
[Install]
WantedBy = multi-user.target
Enable this service on boot with systemctl enable xbmc.service. You need to allow xbmc user to run X. The simplest way is to run dpkg-reconfigure -plow x11-common and to allow anybody to run X. sudo may be an alternative.

Configuration

Sound While I wanted to use PulseAudio, I want the AV receiver to be able to upmix stereo streams itself. With PulseAudio, it would always receive a 6-channel signal. Therefore, I directly use ALSA. First, unmute the appropriate outputs:
$ amixer scontrols   grep IEC958
Simple mixer control 'IEC958',0
Simple mixer control 'IEC958 Default PCM',0
Simple mixer control 'IEC958',1
$ amixer sset 'IEC958',0 unmute
$ amixer sset 'IEC958 Default PCM',0 unmute
$ amixer sset 'IEC958',1 unmute
$ sudo systemctl stop alsa-utils.service
The order of channels is incorrect. With the following /etc/asound.conf, we declare a new output, hdmi2, with a different mapping:
pcm.hdmi2  
  type asym
  playback.pcm  
    type plug
    slave.pcm "remap-surround51"
   
 
pcm.!remap-surround51  
  type route
  slave.pcm "hdmi"
  ttable  
    0.0= 1
    1.1= 1
    2.4= 1
    3.5= 1
    4.2= 1
    5.3= 1
   
 
In XBMC, this output should be used instead of the default one. hdmi should still be used for passthrough. To check if each speaker is mapped correctly, one can use speaker-test -D hdmi2 -c 6.

LCD display The LCD display integrated into the SoundGraph iMON is supported by the imon kernel module and the lcdproc package. I have only modified a few lines of /etc/LCDd.conf to make it work:
[server]
Driver=imonlcd
ServerScreen=off
[imonlcd]
Protocol=1
OnExit=2
Contrast=400

Remote control This is the most difficult part. I have a Logitech Harmony remote which is a great universal remote. Its support in Linux is acceptable: you can configure through Logitech website and use congruity to push the new configuration.

Remote controls and Linux Before Linux 2.6.36, most remote controls would need LIRC to work:
  • The driver receives the signal from the IR receiver and make it available through /dev/lirc.
  • lircd, with the help of a configuration file describing the protocol used by the remote control, will read the signal and turn it into the appropriate LIRC code.
  • XBMC connects to lircd and receives incoming LIRC codes. It will translate them to an XBMC command. This translation is specified in Lircmap.xml.
  • XBMC maps each command to an action (like Play, Fullscreen, ) using a keymap. This keymap can handle commands received by a remote control, but also by a keyboard, a mouse or a joystick.
Since Linux 2.6.36, remote controls will be mapped as a generic input device (just like a keyboard):
  • The driver receives the signal from the IR receiver.
  • The signal will be handled by a decoder. The configuration of this decoder is done in userland by ir-keytable. The decoder will turn the signal into the appropriate event (usually, some keypress).
  • X will listen to those events and turn them into X key events.
  • XBMC will receive them and use the appropriate keymap to turn them into actions.
And to add more complexity to the mix, in this last case, you can still use LIRC: lircd will listen to events generated by the kernel and turn them into LIRC codes. This can be very confusing. Moreover, the SoundGraph iMON IR receiver accepts two IR protocols: the iMON protocol and the RC-6 one. The Linux driver accepts both of them but uses the first one by default. The RC-6 protocol is the protocol used by many MCE remote controls. I hope you are still with me here.

The easy way To get a reasonable configuration out of the box, here is how to configure each layer:
Logitech Harmony remote
Configure it as a Microsoft branded Media Center PC: Windows Media Center SE.
iMON IR receiver
It must use RC-6 protocol. See below for more details.
LIRC
In /etc/lirc/hardware.conf, put DEVICE=/dev/input/by-id/usb-15c2_0038-event-if00 and DRIVER=devinput. In /etc/lirc/lircd.conf, just put include "/usr/share/lirc/remotes/devinput/lircd.conf.devinput".
XBMC
With the previous bits done, it should just work out of the box.
To switch to RC-6 protocol, install the ir-keytable package and use the following commands:
$ sudo modprobe rc-imon-mce
$ sudo ir-keytable -s rc0 -p rc-6 -c -w /lib/udev/rc_keymaps/imon_mce
Read imon_mce table
Old keytable cleared
Wrote 77 keycode(s) to driver
Protocols changed to RC-6
To make the change permanent, add the rc-imon-mce module to /etc/modules and create /etc/udev/rules.d/90-imon.rules with the following content:
# Override the keytable for iMON
ACTION=="add change", SUBSYSTEM=="rc", DRV_NAME="imon", \
   RUN+="/usr/bin/ir-keytable -s $name -p rc-6 -c -w /lib/udev/rc_keymaps/imon_mce"

The hard way Now, you may want to bind custom actions to some (physical or virtual) buttons. Basically, you are left with two solutions:
  1. Start from the basic configuration with LIRC and add more buttons at each levels (there are five of them!).
  2. Remove LIRC and start with the Logitech Harmony acting as a Microsoft MCE keyboard.
The first option can be quite difficult. You need to find an unused code for the Logitech Harmony. You can try to make it learn a new code if you have some RC-6 remote control. Then, you need to ensure that this code will be present in the keytable used by ir-keytable. If not, you need to add it. That s not easy since you need a to enable some debug stuff in the kernel to find the appropriate scancode. After that, the code needs to be translated in lircd.conf. You will then have to translate it again in Lircmap.xml. At least, you need to add it to a keymap in XBMC. The other way is not ideal but seems less cumbersome. The first step is to configure the Logitech Harmony as a Microsoft MCE keyboard: it has a lot of available keys. Because of the lack of multimedia keys, let s match the keyboard configuration of XBMC:
Button Command Button Command
Channel Down PageDown Stop X
Channel Up PageUp Skip back Comma
Prev Backspace Skip forward .
Up DirectionUp Play P
Down DirectionDown Rewind R
Left DirectionLeft Fast forward F
Right DirectionRight Star Delete
OK Enter Pound W
Menu C Red F1
Exit Esc Green F2
Guide Tab Yellow F3
Info I Blue F4
Unfortunately, the keytables provided with ir-keytable are not complete enough. I have built a more complete table3. With this table and the bindings described above, most functions will work out of the box without LIRC. Additional keys can be configured in a dedicated keymap4. Here is an excerpt of mine:
<keymap>
 <global>
  <keyboard>
    <end>XBMC.ShutDown()</end>
    <f1>XBMC.ActivateWindow(MusicLibrary)</f1>
    <f2>XBMC.ActivateWindow(Videos,TvShowTitles)</f2>
    <f3>XBMC.ActivateWindow(Videos,MovieTitles)</f3>
    <f4>XBMC.ActivateWindow(Weather)</f4>
  </keyboard>
 </global>
 <FullscreenVideo>
  <keyboard>
   <opensquarebracket>SubtitleDelayMinus</opensquarebracket>
   <closesquarebracket>SubtitleDelayPlus</closesquarebracket>
   <f6>xbmc.runscript(script.xbmc.subtitles)</f6>
  </keyboard>
 </FullscreenVideo>
</keymap>

FTP Instead of using SSH, I prefer to drop new files with anonymous FTP. vsftpd fits this purpose. Here is my configuration file:
listen=YES
xferlog_enable=YES
use_localtime=YES
setproctitle_enable=YES
secure_chroot_dir=/var/run/vsftpd/empty
nopriv_user=ftp
ftpd_banner=XBMC
hide_ids=YES
ftp_username=xbmc
anon_umask=022
anon_root=/home/xbmc/media
anonymous_enable=YES
write_enable=YES
anon_upload_enable=YES
anon_world_readable_only=YES
It is currently not compatible with systemd (see bug #670308). I have removed the symlink in /etc/rc2.d and I have used the following unit file:
[Unit]
Description=Vsftpd ftp daemon
After=syslog.target network.target
[Service]
Type=simple
ExecStart=/usr/sbin/vsftpd /etc/vsftpd.conf
ExecReload=/bin/kill -HUP $MAINPID
ExecStartPre=-/bin/mkdir -p /var/run/vsftpd/empty
[Install]
WantedBy=multi-user.target

Miscellaneous
  1. In /etc/default/grub, reduce TIMEOUT to 0 to shorten the boot time.
  2. Enabling dirty regions can help speed up XBMC.
  3. aptitude install upower pm-utils to be able to shutdown/suspend from XBMC. Since XBMC was configured to be started outside any session, you need to explicitely give the appropriate rights by creating the following /var/lib/polkit-1/localauthority/50-local.d/xbmc.pkla:
    [Actions for xbmc user]
    Identity=unix-user:xbmc
    Action=org.freedesktop.upower.*;org.freedesktop.consolekit.system.*
    ResultAny=yes
    ResultInactive=yes
    ResultActive=yes
    

  1. The readibility of the LCD screen is very bad. You should look at the VFD version. The IR receiver reception is poor. The provided remote control is a joke.
  2. Debian Wheezy is not yet released. If you are unfamiliar with Debian, it may be cumbersome to maintain it until the freeze happens in a few months.
  3. Some keys are missing from the provided table. For example, there is no exclamation mark. While there is a scan code for such a key in RC-6 protocol, there is no appropriate key code to translate to: on a QWERTY keyboard, the exclamation mark is on the same key as the number 1. It is possible to map it to some other key code, but the mapping would have been difficult to use.
  4. For example, in ~/.xbmc/userdata/keymaps/harmony.xml.

Tanguy Ortolo: Debian: switch to UEFI boot

UEFI logo: a cube with u, e and fi written on each visible face For those interested, here is a way to install Debian and boot it with UEFI if you have an UEFI motherboard. Using UEFI with Debian requires expert knowledge so if you do not feel up to it, keep your BIOS system. 1 Background UEFI is a specification for motherboard's firmwares which is replacing the old BIOS. For now, UEFI motherboards still include a BIOS compatibility layer. The UEFI boot process is quite different from the BIOS one. It involves one specific piece of the motherboard's firmware, the UEFI Boot Manager, which is able to load boot loaders from FAT file systems on specially-typed partitions. It can offer a boot menu (boot: Debian from HDD, Windows from HDD, USB stick, DVD?), which can be configured from a running operating system. So, basically, to boot a system with UEFI, you need two things: 2 Installation or preparation If you are installing a new Debian system, read the first part. If you already have a BIOS-bootable Debian system installed, read the second one. In both cases you will have to use Debian testing, because stable's GRUB has problems with UEFI. You can also use Debian stable while taking only GRUB from testing though. 2.1 Installation of a new Debian system There is no installer image for UEFI, so you can either: The installer does not provide a convenient way to install an UEFI boot loader, so you are going to install a regular BIOS boot loader at first, and switch to UEFI later. Use the expert mode and format your hard drive with a GUID Partition Table (GPT). Create a small partition (1 MiB would be far enough), type it as a BIOS Boot Partition (this is the untitled flag above the bootable one in Partman), do not format it and do not mount it: this will be needed for BIOS booting. Create another small partition (same kind of size), type it as an EFI System Partition (this is the bootable flag), format it as FAT and mount it on /boot/efi: this will be needed for UEFI booting. Finish the installation as usual, installing GRUB for BIOS, and boot your new system. 2.2 Preparation of an existing Debian system for UEFI You need to use a GUID Partition Table on your hard drive. If you used an MBR, you lost; you may try to convert it to GPT using a tool such as gdisk, but that means operating without a net, loosing your current boot loader in the process. If there is no space left on your hard drive, use Debian Live to make some. Create a small partition (1 MiB would be far enough), type it as an EFI System Partition, format it as FAT and mount it (permanently, using the fstab) on /boot/efi (that directory will not exist, so create it first). 3 Switch to GRUB UEFI Install the package grub-efi-amd64. Prepare it by running the command (assuming your hard drive is /dev/sda):
# grub-install /dev/sda
That will do three things:
  1. generate a GRUB image;
  2. install it to the EFI partition at efi/debian/grubx64.efi;
  3. try to configure the UEFI Boot Manager (the motherboard's boot menu) to load it on start-up
That last step will fail. This is expected, because the UEFI Boot Manager can only be configured from an operating system that was started from UEFI. So if you stop here, you get an unbootable system. Now, copy (a symlink would be relevant here, but that cannot be done on a FAT file system!) the GRUB image to that other path on the EFI System Partition: efi/boot/bootx64.efi. This is where the UEFI firmware looks for a boot loader when it has not been configured for a specific path, typically on removable media. Reboot to check that If that trick worked, you are now on UEFI-booted system. Run grub-install again, which should now succeed to configure the UEFI Boot Manager. Reboot to check that you get a debian entry on the motherboard's boot menu, and remove efi/boot/bootx64.efi which is no longer needed.

24 April 2012

Michal &#268;iha&#345;: phpMyAdmins projects in GSoC 2012

There already has been official announcement for this years GSoC at phpMyAdmin and it's time to share my bits. First of all more details about chosen projects are available on our wiki (missing bits will get updated soon). This year I'll be mentoring again three students. As usual, it was quite tough job to choose students and I hope we've chosen really good ones. Anyway we'll see this later during there summer :-). As we're currently on a (long) way to phpMyAdmin 4.0, basically all projects are somehow about cleanup and refactoring of quite historical code which lives in some dark places of phpMyAdmin. The only big difference is automated testing project, which is purely about writing new test cases and making tests cover more functionality. Anyway I'm looking forward to see first improvements from my students - Alex Marin, Yasitha Pandithawatta and Chanaka Indrajith.

Filed under: English Phpmyadmin 0 comments Flattr this!

Jonathan McDowell: The future is here again

Back in 2004 when Simon and I went full time with Black Cat one of the first things I did was sort out an ADSL offering, including native IPv6. We were one of the first UK ISPs to offer this (possibly the first; I know A&A had been doing tunneled IPv6 for a lot longer, but I'm not sure exactly when they enabled IPv6 on the PPP session. Also Bogons were fairly quick to enable it as well). By the middle of 2004 I was fully IPv6 enabled; my colo box had a native connection, my entire home network (a /64 for the wired, a /64 for the wireless) was configured, BCN had multiple native IPv6 connections to other ISPs (such as peering over LoNAP). By and large it just worked; I remember at one point looking at a traffic graph link from someone in Australia and them indicating surprise that I'd come in over v6. I hadn't noticed anything different than normal, which is exactly how it should be. When we sold BCN in 2007 unfortunately one of the casualties was the v6 support. The ISP that took over the ADSL wasn't setup to be able to continue the v6 support, nor were RapidSwitch, who took over most of the hosting (I note with sadness that RapidSwitch still don't seem to be offering v6, though they keep saying it's a work in progress). So I stopped having any v6 for some time, refusing to slum it with a tunnel. This changed at the start of last year, when I sought out new hosting for the. I ended up selecting Bytemark, partly because I knew of their commitment to v6. I'd chosen Sonic as my US access ISP, again partly because they offered an IPv6 tunnel service (while not as nice as native v6 over the DSL I felt that a tunnel provided by the DSL ISP was acceptable for access). However a combination of not having a machine that was always on at home, and a dynamic IP on my connection, meant that I never got round to configuring anything permanent up. Recently I got around to buying a little low powered box to be always-on and this week I finally looked at configuring it up as the tunnel endpoint, planning to do some sort of screen scraping of the web interface to automatically update the tunnel broker information for the rare occurrences when my IP changes. The first nice surprise was that Sonic are now doing static IPs for free (previously you could only have a block of 8 for $20/month extra). That makes things a lot easier. So tonight I configured up the little server as the tunnel endpoint, installing radvd and some basic v6 firewalling. As expected my laptop sees the RAs, automatically configures everything up and my ssh sessions start to go over IPv6 instead. Looks like my phone also does the same. I'm not entirely sure what the NAT on the ADSL router is doing and if inbound connections will fail if there's nothing outbound holding the translation entry active, but I'm sure I can work around that if it turns out to be a problem. I care more about access than hosting anything on the end of my DSL anyway. This means I'm finally almost back to where I was nearly 8 years ago, just in time for World IPv6 Launch day.

Next.

Previous.