Jolla's Sailfish: MeeGo resurrected

Looks like today is mobile OS day. A little earlier I posted about my kindling interest in Firefox OS, and now I just read stories on Slashdot and Engadget  about Jolla's pending release of their MeeGo-based Sailfish operating system.

While sources claim Jolla's efforts are open source, I'm concerned about a line from a source linked to in the Slashdot article that states, "Jolla's plans will not include open sourcing [Sailfish's] user interface layer that it is building on top of the operating system platform." Which, of course, means that whatever Jolla ships won't be FOSS. At this point I have no idea if the non-FOSS UI layer is simply widget styling and branding (not a deal breaker) or something more crucial (potentially a deal-breaker). I hope to see this clarified soon.

An interesting difference/similarity between Firefox OS and Jolla is their marketing strategies. While Firefox OS seems to be targeting Sino-centric markets only obliquely (by targeting low-end hardware), Sailfish is targeting Chinese handsets directly. Just how this plays out globally will be interesting to watch.

Penguin meets canine: Firefox OS

I was originally somewhat dismissive of Mozilla's Firefox OS (née Boot to Gecko) as just a Google Chrome OS wannabe, but I've read a few things recently that suggest it's a platform with some good ideas that might actually gain some traction. While there seems to be limited buzz about it in $illyValley, and some are predicting very low penetration next year, I want to be optimistic that it will develop into a platform with some relevance.

I'm attracted to Firefox OS because unlike Google Chrome OS or Android it's all open all over the place, and unlike webOS it actually has institutional backing.*

FfOS's strategy is to target low-end smartphones and featurephones--a place that iOS will likely never go and where Android is going with only limited usability success. In addition to phones, I am wondering if FfOS might also be applicable to general embedded device development. Qt+QML seems to do nicely in this space, but I am more than slightly concerned about the future of Qt since being dumped by Nokia. webOS seems a good candidate for embedded work as well--as long as you subscribe to the webOS UI paradigm.

In any case, it's always nice to have viable alternatives, so I'll be rooting (!) for the ruddy canine.

*Looks like I might be wrong about this.

Fixing Qt appearance under XFCE 4.8 (aptosid)

On my aptosid setup running Xfce, Qt apps don't honor the GTK appearance setting without some help. The post at http://forum.xfce.org/viewtopic.php?id=5605 provides a solution that worked for me:

# echo 'export GTK2_RC_FILES="$HOME/.gtkrc-2.0"' >> /etc/profile.d/qgtkstyle.sh
# chmod 755 /etc/profile.d/qgtkstyle.sh

then logout and back in.

With Xfce taking on increasing importance since the introduction of GNOME 3, I hope this will work out-of-the-box in the near future.

frEDA SPICE 4: KiCad component repository

I have created a Mercurial repository for my KiCad SPICE component libraries at https://bitbucket.org/mithat/kicad-spice-library. At the moment it covers the same components as the PSpice library that ships with KiCad but renamed and drawn to be more consistent with IEC specs. I will add controlled sources and other SPICE primitives as time and necessity allow.

frEDA SPICE 3: KiCad components

KiCad ships with a small library of SPICE components (installed as /usr/share/kicad/library/pspice.lib  in Debian). It's nice that it does because it lets you do some basic testing with little investment. However the library has a couple shortcomings:

1. Many SPICE primitives are absent (e.g. controlled sources).
2. Some of the components could look better (i.e., more consistent with IEEE or IEC specs).

So, yesterday I began to implement a new library based on the existing one. As soon as it's anywhere close to complete I will publish it in a source code repository somewhere.

frEDA SPICE 2: ngspice

Out of the gate, my frEDA SPICE effort hit a small stumbling block. It turns out that (for reasons that are not clear to me) ngspice in Debian testing and sid is available only for amd64 and in stable only for i386. (You might also note that ngspice is considered non-free in Debian.) And of course I'm using testing i386.

So, time to compile. To get config to complete without errors, I had to install a bunch of {something}-dev dependencies, but once I had all the dependencies in place it seemed to compile and install just fine.

Next step, integration with KiCad.

frEDA SPICE 1: motivation

I've been getting back into analog electronics design, and related to that I've decided to try to use libre EDA tools as much as possible--an effort I've opted to call frEDA, for free Electronic Design Automation. The interpretation of libre in this context is, "as libre as possible for getting the necessary work done."

When it comes to circuit simulation, SPICE is really the only protocol that will work for my needs. So any solution I contemplate must be if not itself a SPICE implementation then at least fully SPICE compatible. And if there's anything like a classic libre toolset for this, it might be gschem from the gEDA project and the ngspice SPICE engine. (Lots of people seem to like gnucap as well, but it's not SPICE-compatible.)

gschem is capable of some really nice things, but I've decided instead to see how well a KiCad and ngspice pairing works. This is for two reasons:

1. gschem isn't officially supported on Windows--and while I use Linux as my main OS, I know plenty of people who (need to) use Windows.
2. Inasmuch as I have begun using KiCad for PCB layout, it would be nice to avoid having to learn and maintain a new schematic capture tool just for SPICE.

So, the current (pun!) workflow looks something like:

1. Pick a SPICE engine, probably ngspice.
2. Do some experiments to see if there are any nasty gotchas using it with KiCad-generated netlists.
3. Make a library of basic SPICE components for KiCad.
4. Frosting: Investigate tools for drawing SPICE generated output.

I will post updates as anything interesting develops.

Fixing CodeBlocks AVR build problems on Debian Wheezy

This might be a bit off-topic, but I didn't know where else to put this.

I spent a good part of this evening trying to figure out why I could build AVR projects in CodeBlocks using an old profile (i.e., personality) but not a new one. When I tried to compile with a new one (even on a different machine), the compile would generate a

/usr/include/features.h:323:26: fatal error: bits/predefs.h: No such file or directory

error.

By comparing the old and newly created profiles, I was able to figure out that new profiles were setting default include directories for building indiscriminately versus not at all for the old profile. The following seems to fix things, but to be honest I have not tested a wide variety of AVR builds nor have I tested any other kinds of projects. But I can't see why it should mess anything else up.

1. Open Settings > Compiler and debugger... > Global compiler settings
2. Under Selected compiler, select "GNU AVR GCC Compiler"
3. Select the "Search directories" tab
4. Select the "Compiler" tab
5. Select the /usr/include entry and click the "Delete" button
6. Right next to the "Compiler" tab, select the "Linker" tab
7. Select the /usr/lib entry and click the "Delete" button

AVR builds should now succeed. This fix should work with additional profiles you add as well as to the default.conf profile.