Tech Blogs

Zkusme se dnes podívat na distribuci QtMoko. Pokud ji nemáte, možná vás překvapí, že její použitelnost je relativně vysoká. Kde se vzalo... QtMoko je jedna z distribucí, které pro telefonování používají komplexní telefonní aplikaci Qt Extended. Vývojem Qt Extended (možná jste ji znali pod starým názvem QTopia) se zabývala společnost Trolltech (dnes Qt...

OpenMagazin je společný projekt několika portálů věnujících se svobodnému software. Každý měsíc vychází výběr z těch nejlepších článků. Počínaje číslem 10/2009 si můžete přečíst také vybrané články z našeho portálu. OpenMagazin stahujte zde. Z obsahu partnerských portálů vyzdvihnu především článek První...

V dubnu 2009 byl odložen vývoj mobilního telefonu 3D7K (původně GTA03), následovníka Neo FreeRunner, na neurčito. Zároveň byl oznámen záhadný projekt Plan B. Nikdo však nevěděl o jaký Plan B půjde, ale podle dostupných informací má jít o mobilní zařízení třikrát levnější než 3D7K a bez GSM modulu, tedy nemá se jednat o další...

Dne 18.7.2009 od 10.00 bude probíhat linuxový sraz v pivovaru v Berouně u Prahy. Na programu jsou přednášky a diskuze o Linuxu a hlavně přednáška o Openmoko, kde se po nezbytném úvodu dozvíte co se za poslední rok událo, co nás v nejbližší době čeká, jaké jsou plány okolo Openmoko do budoucna a jak se aktivně podílet na vývoji Openmoko. Dále budou...

Recently I was cleaning up some of my GIMP# code. One of the constructions that is often used is something like this: var image = new Image(width, height, ImageBaseType.Rgb); image.AddLayer(new Layer(image, "layer", ImageType.Rgb), 0); The code above creates a new RGB image with a certain width and height and adds a new layer to that image. As you [...]

Hello mojoPortal community,

I would like to gather your feedback about something I am contemplating. Not long ago I implemented a new data layer for Sql Azure. I could have just made changes in the MS SQL data layer to make it compatible. The biggest change would be that ntext fields must be changed to nvarchar(max). There are a few other changes needed to support Sql Azure but that is the main issue as we are currently using ntext all over the place. The problem is that nvarchar(max) was introduced in SQL 2005, so doing this would be explicitly dropping support for SQL 2000 in mojoPortal. Doing this would be very beneficial to me because I could consolidate into 1 data layer that supports SQL 2005, 2008, and Azure and this would reduce maintenance by eliminating the need for an extra data layer for Sql Azure. 

So, what I'm trying to guage is how many of you are using SQL 2000?

It is 10 year old technology after all and at some point it seems like we should be able to drop support for it. If I were to drop support for it sometime soon how many of you would be chasing me with pitch forks?

Thanks,

Joe

Joe Audette  ...

Monday I released Tomboy 1.1.4. Last month's 1.1.2 release was actually the first to feature automatic note synchronization (herein referred to as 'autosync'), but in 1.1.4 the feature is less annoying and you can actually turn it on in the Preferences UI. Here's the only possible autosync screenshot:


Here are some facts about autosync:

• It assumes the server is always right when conflicts occur, so if you actually found Tomboy's conflict-handling UI useful, don't use autosync
  
• When a sync occurs, it desensitizes all note windows, because Tomboy sync is still a bit insistent on believing in transactions.
  
• But in theory this should never be a problem for you, because Tomboy will never sync while you are editing a note. It will wait until *at least* one minute has passed where you have not been editing.
  
• Besides this desensitization of note windows, there is no indication at all that a sync has occurred. Next cycle, I intend to use libnotify bubbles and/or status icon changes where they make sense to let the user know if new updates have been downloaded, or if the sync server appears to be down, etc. Right now this feature is totally silent, though you can get a few details if you run from a terminal with --debug.

It's unfortunate that I've been too busy to publicize this feature until so very late in the cycle. I'd appreciate any testing, feedback, bug reports, etc. At this point all I can say is that it Works For Me.

Other sync-related news:

• Rumor has it that Ubuntu One note sync can no longer mangle your notes, unless you use their web editor, in which case the mangling is much less severe than in the past. I keep getting emails from Launchpad saying that Rodrigo has fixed yet another of the old irritating bugs, to the point that I've lost track and think he may have gotten the last of them! :-) This is great news for U1 users, who previously suffered from a few serious sync bugs.
  
• I've started the ball rolling on deploying Snowy on GNOME servers (this would be known as Tomboy Online, if the marketing team approves...I still need to email them).
  
• We have another Snowy planning meeting this weekend.
  
• Many thanks to Leon Handreke and Sander Dijkhuis for their valuable contributions to Snowy in git.
  
• Tomdroid 0.3.1 is out, and although it doesn't yet include web sync, the merge is impending!

Another feature in Tomboy 1.1.4 makes me very happy, might upset Tomboy old-timers, and could possibly cause Alex Graveley to destroy my very soul:

By default, when you rename a note, Tomboy will no longer automatically update all of the text that used to link to that note. Instead, if other notes link to the renamed note, Tomboy will show you a dialog (lame, I know, I intend to bind GtkInfoBar for next cycle to eliminate all dialogs in Tomboy) that lets you choose what to do. Here's an example screenshot, with the Advanced section expanded:



Some have argued that automatic link renaming is part of Tomboy's magic, but many many users (including me) consider this dark magic to be a serious potential data loss bug. If you've ever had a note called "Linux", and renamed it to "openSUSE", and been dismayed to find that everywhere in your notes where it used to say "linux" it now says "openSUSE", you know what I'm talking about.

In the future, I'd like to allow folks to have more control over note linking behavior. Many users have expressed a desire to turn off automatic linking, or to be able to link arbitrary text to another note (not just text that matches the note's title). Enough people have asked for it that it'll probably happen, though of course patches would make it happen faster.

Next time you hear from me, Tomboy 1.2.0 should be out, and we should be making progress on getting Tomboy Online deployed!

In the Unite 2009 conference keynote we promised you that Unity would be picking up speed, and it has: Unity has become a powerhouse in the game industry and beyond. Nobody else is as active in democratizing sweet game technology to as many developers, and enabling them to target as many consumers. Unity has been [...]

I just found this little EFL-testapp:

It’s an app written by Gustavo Sverzut Barbieri. It’s an Iphone like virtual keyboard. You can find the sourcecode on googlecode..
I had to apply a little change to the code, to get it running on the Freerunner.
I changed lines 206-210 to this:
if ecore.evas.engine_type_supported_get(“software_16_x11”): ee = ecore.evas.SoftwareX11_16(w=WIDTH, h=HEIGHT)
else: print “warning: x11-16 is not supported, fallback to x11” ee = ecore.evas.SoftwareX11(w=WIDTH, h=HEIGHT)

Maybe someone likes to modify this code and build a real virtural keyboard for SHR out of it?
I hope i could motivate someone, as this would be a really nice keyboard.

Wow - it has been a long time since my last post... and with good reason ;)

Firstly I've been busily writing (along with Wally, Chris, Martin & Rory) for Wrox' upcoming Professional iPhone Programming with MonoTouch and .NET/C# which is available for pre-order on Amazon. If you are interested in developing for the iPhone using C# and the .NET Framework it should be a great addition to all the resources already out there on the web.


Secondly I've been working on an iPhone app for MIX10 in Las Vegas next week (with help from Chris, Miguel & Geoff). It is now available FREE on the AppStore and has a website at mix10.confapp.com. Whether you are heading to MIX or just curious about C# and MonoTouch on the iPhone, why not download and give it a try?

Since the MIX10.app was first 'announced' on twitter #MIX10 there have been a number of requests for the source code. Unfortunately the source isn't public at the moment, however that doesn't mean we can't talk about "how it works". To start with, the MIX10.app is based on two previous iPhone apps written in C# with MonoTouch, and whose source code is available:

• Monospace09 code is on github and is discussed on my blog (and here)
• PDC09 is on github and discussed in this post

If you have an Intel Mac (with Snow Leopard) then you can download both the Apple SDK and the MonoTouch trial version for free and get both these C# .NET examples running in the iPhone Simulator for yourself. To deploy on a real iPhone requires certificates and licences (from Apple and Novell/MonoTouch respectively).

MIX10.app
Here's the overall class diagram for the MIX10.app (with the views shown too). Even without seeing the code it's clear that the classes themselves are not overly complex (ie. few methods are required; and inheritance can be leveraged to share common functionality).


The MIX10.app also uses Miguel's MonoTouch.Dialog framwork and he's posted a snippet of code on gist.github which is responsible for this screen (on the left)




And he also posted this code which creates the 'My Schedule' view on the right. Pretty neat use of Linq, eh? I'm not sure I've seen such an expressive user-interface expressed in so few lines of code before...public class FavoritesViewController : DialogViewController {
public FavoritesViewController () : base (null) { }
public override void ViewWillAppear (bool animated)
{
var favs = AppDelegate.UserData.GetFavoriteCodes();
Root = new RootElement ("Favorites") {
from s in AppDelegate.ConferenceData.Sessions
where favs.Contains(s.Code)
group s by s.Start into g
orderby g.Key
select new Section (MakeCaption ("", g.Key)) {
from hs in g
select (Element) new SessionElement (hs)
}
};
}
}The object model closely follows the data available from the api.visitmix.com site's OData and RSS feeds. These are plain vanilla C# objects which also run on the server to download and package the data for the iPhone - the object graph is serialized by a .NET application on Windows Server 2003, downloaded by the WebClient class on the iPhone (thanks to MonoTouch) and de-serialized ready for display. A perfect example of the cross-platform possibilities facilitated by MonoTouch and having the .NET framework available on both server and mobile device.


Finally, here's a quick overview of ALL the screens in the app. Did I mention you should give it a try?


...and if you're a Windows Phone Series 7 fan-in-the-making, it should be obvious that having a shared set of services and functionality in C# that can be deployed across iPhones with MonoTouch, and Silverlight/Windows Phone 7 with only UI code needing to be customized is a great way to achieve maximum reach for your apps. The MonoTouch Roadmap is also targetting a Q3 release of MonoDroid, so with a bit of imagination it isn't hard to see where the future of cross-mobile-device development is heading...

Pokud jste ještě nezachytili, na oficiálním serveru QtMoko jsou k dispozici images QtMoko v18. Pro image byl použitý novější linuxový kernel 2.6.32 (původní v19 byla na kernelu 2.6.29). Mimochodem testovací images na SHR je taky venku: http://build.shr-project.org/tests/mrmoku/kms/images/om-gta02   QtMoko v18 je spíše testovací, prý ale funguje dobře (nezkoušel jsem). Radek...

In the past weeks (actually, months) I've been doing some changes in the MonoDevelop GUI to make it more functional and better looking. Here is the result:
Before


After


Changes in the Status Bar
Everything started with the idea of removing the status bar, in order to save space in the main window. The plan was to use something similar to Chrome's status popups, which are visible only when there is actual information to show to the user. However, after playing with the idea and thinking about how would it fit in MonoDevelop, I decided to try something else. Instead of removing the status bar, we would make a better use of the space it takes. So in the new GUI I merged the status bar and the bottom dock bar. The dock bar is the area where the title of pads in auto-hide mode are shown (for example, the Test Results pad in the above screenshots). When you hover over the title, the pad is shown in a popup window, with a nice sliding effect. The bottom dock bar is now shown next to the status bar, growing as more space is required.

I also added support for custom pad labels. So for example, the Errors List pad now shows the error and warning count, instead of just the "Errors List" label. In this way pads can show some status information while they are minimized.
Less intrusive output pads
Temporary output pads such as logs for Version Control or Find in Files operations are now shown in autohide mode by default. Until now, those pads were shown docked at the bottom, taking space from the text editor. I also removed the standalone Build Output pad. The build output is now available in the Errors List pad, by clicking on the Build Oputput button:

Visual improvements
A noticeable visual change is that the main window new has a darker background, with some subtle shading effects. The pads look more "physical" and better delimited. The pad toolbars are now integrated in the docking system, improving the overall visual consistency.

Configurable GUI compactness
One thing I learned while working in MonoDevelop is that it is hard to find the right balance in the use of padding between the gui components (specifically, between the components shown in the main window). Using more padding makes the GUI more visually pleasant, and the components are better delimited. On the other hand, padding may be a waste of space when working on small resolutions.
I added a configuration option for selecting the level of compactness of the GUI. There are five levels, from Very Compact to Very Spacious. So for example, the screenshots shown above are using the 'Spacious' level. In that level, there is some padding always visible between the pads, the window borders and the main menu. There is no such padding in 'Normal' mode.

Zoomable tree views
MonoDevelop has an option which allows choosing the font to use for the tree view pads such as the Solution pad or the Class pad. Those trees may be large for big projects, so users find it convenient to use a small font, which allows seeing more information at once.
To make font reduction easier and more handy, I added a Zoom capability to the tree pads. So to zoom, all you have to do is hold the Control key and move the mouse wheel up and down (the standard zoom shortcuts can also be used for this, including Control+0 to reset the zoom). This screenshot shows the solution and class pads with different levels of zoom:

Conclusion
The changes I described are part of an ongoing effort to make MonoDevelop easier to use. There is more to come. It would be great to have feedback on the changes we are doing, so that we can further fine tune the interface for the 2.4 release.

The MonoTouch app Project-D has been unveiled as Diggify and is coming soon to the AppStore.

oFono je opensource telefonní framework, jehož vývoj je sponzorován Intelem a Nokií. V podstatě se jedná o konkurenci freesmartphone.org. Nebudu zde nyní rozvíjet rivalitu mezi oFono a FSO, ale představím vám první (o které vím) distribuci založenou na oFono frameworku, distribuci Neophysis. A na čem jiném by tato distribuce běžela než na Openmoko Freerunneru :) - ať chceme nebo nechceme,...

Each time someone starts writing on distributed development there are some arcane and obscure commands that immediately show up to specify how the changes have to be popped from or pushed to some freely available internet repository. And that's fine, but most of the developers out there are more used to right menus, dialogs and options than typing on black consoles. So at the end it looks like distributed development is something for open source developers working on Linux, and that's obviously not true.

Let's try to describe the whole picture and how you, as a Windows developer most likely working on a commercial project for your company, can also benefit for the new trend of going distributed.

Your current scenario

So, you're using Visual Studio on a daily basis and committing changes to your version control, getting updates from the rest of the team and potentially creating tons of small feature branches to better isolate your code changes (if you didn't embrace yet branching then I bet it will be a great first step before going distributed, but keep reading to check how it will also benefit you).

You probably have several workspaces to work on different projects or just to focus on different tasks without having to update the whole thing again and again (which should be also fast, but you know?).

So basically you go to one of your working copies, make changes from there, and submit there to your central server at the office which lets you forget about how or where the data is stored and it is powerful enough to run very fast and make your life easy :-P.

What this distributed thing is all about?

It's much simpler than you think. Let's start with a nice scenario: suppose you've decided to work at home for a week, avoiding the daily traffic jam and having some spare time at noon to do a break and practice some sports close to your place, sounds good? (Later I'll describe another not so beautiful scenario).

The situation will be something like the following picture, where you've access to your version control server only through a VPN or network connection.

The main issues you'll face will be:

Connection can be lost, slowing you down, having to reconnect and simply making you lose time.

Connection can be slow: switching to a different branch or simply committing or retrieving changes will be painfully slow.

What's the solution? Going distributed. Imagine you've your own version control server on your laptop, so you don't have to connect to the office's central server anymore, everything will be extremely fast, no waits, no connections being lost! Of course, since your laptop won't be as powerful as the central server, you don't need a full copy of all the repositories but only certain parts of the ones you'll need to work with, so you can keep making changes and then synchronize them back with the central server when you're back at the office or through the network when you decide to send them back.

The advantages are clear:

You can move your laptop from work to home (or whatever different locations you can think of) and you'll always be able to continue working seamlessly.

You won't have to wait for changes to be downloaded to your machine from distant locations through slow and unreliable networks.

You're free to continue making changes having full version control support (hey! You can try a poor's man approach just copying a workspace to your laptop, but then you won't be able to access file history, switch branches, make intermediate commits and all this things you get used to when you have version control).

Alternative scenarios

As a professional developer there are many scenarios where you can benefit from distributed development. The one described above, working at home, is just one of them but there are many other chances like:

Working on the customer's site for some days (or even much longer) and still being able to do controlled changes to the source code.

Attend a demo, event and so on and still be able to try a nice change on the code but doing so in a controlled way.

The multi-site scenario: connecting several teams by using distributed development between their servers.

Hands on lab: what to do next

Once the theory is clear, let's just make it happen. Here're the steps we're going to follow:

Set up a server on your laptop.

Import the repositories you need from the central server.

Start working on your distributed server at your laptop.

Submit your changes back to the central server.

Get changes from the central server.

Set up your own "server"

Depending on the version control system you're using it will require different steps. Let me clarify:

If you're using an open source system like Git you won't have a server as such, it will just be a local copy on a directory (typically your workspace) so set up is fast and easy. You can download the Windows installer from here: http://code.google.com/p/msysgit.

If you plan to use Mercurial you can find the download here: http://mercurial.selenic.com/downloads. Mercurial includes a small HTTP server that allows you to synchronize with other servers and other people to take changes from you.

If you plan to use Plastic SCM you can set up the client and server on your machine in less than 45 seconds as you can see in this video: http://www.youtube.com/watch?v=CVlsVtxZUkk. Plastic is meant to be used from a graphical user interface from day one, so it will be pretty straightforward to use (you know I'm obviously biased here, but just check it and judge it yourself).

Unfortunately for Windows developers out there, Team Foundation Server is out of the picture since it simply does not support the distributed workflow. Although it can be installed in less than 45 minutes :-P.

Your server (whether is a real one or just a directory with a copy like in Git) will hold your replicated data and will let you work with your code while you're disconnected.

Replicate from the central server

Once you've your server set up you need to perform an initial code import from the central server. To make things simpler suppose you're only going to work on a single project while disconnected from the central location. Then you'd have to replicate (or clone depending on your specific SCM jargon) one single repository into your laptop.

Normally you won't replicate the entire repository but only part of it. What does it mean? Your central repo will contain hundreds if not thousands of feature branches, releases and so on, but it will be enough for you to work distributed if you get the main or master branch into your cloned repo.

You can have a very big central repo with many branches like the one on the previous picture but you only need the main one to start working.

So the clone process will just mean replicating the remote main branch into a new local repository on your laptop.

You can do that with Git using the git clone command, or you can do that with Plastic even within Visual Studio as you can see on the following picture.

You can see how I've specified centralserver as the replication source and then a new repository I've just created on my laptop as destination. I click on replicate and the import process starts, as you can see on the following screenshot. (Remember I'm driving the whole process from within Visual Studio 2010).

The initial clone can take a little longer depending on the size of your repos (and the speed of your connection, so it's better if you do it while you're on the same network!), but the good thing is after that all the following operations will be extremely fast.

And once you're done replicating you can browse the changes on your new repository, which will contain all the commits (or changesets depending on your SCM) and labels (tags) coming from the central server.

The version control will keep track of which is the source of each element being replicated. For instance, in the previous screenshot you can see how the selected commit is coming from the remote repository you've just replicated (check the properties tag).

Start working on your laptop disconnected from the central server

You've already completed your initial clone, so it's time to start working on your code without having to be slowed down but your central server.

The pattern I'm going to recommend is using feature branches (or the good-ol branch per task branching pattern as you can find here: http://www.cmcrossroads.com/bradapp/acme/branching).

What does it mean? Well, for every bugfix or new feature you're going to implement you'll create a brand new branch, make your changes there and get them integrated into your main branch (or master or trunk depending on your jargon) later.

It's much, much easier than what you might think. Just google for
feature branches if you need more information on the subject, but it's really simple as you'll see.

Creating a new branch is an easy task on any modern version control tool. I'm showing how to do it with Plastic SCM and Visual Studio: I'm going to create a branch from a given changeset as you can see on the following screenshot. I just right click on the changeset and select create branch from this changeset. Different SCMs will do it on a different way but as soon as they're ready for branching (which is unfortunately not true for all of them), it won't be hard to do.

With Plastic SCM you'll find a dialog like the following where you can specify some extra data about the branch to create like comments, name and so on.

Since I'm just going to fix a bug on the new branch I give it a meaningful name. Note: it's very important to follow some sort of naming convention for feature branches since you're going to deal with a big number of them. My favorite is giving them a certain prefix and then a number, which is directly taken from the associated issue on the bug/issue tracking system.

After the branch has been created your situation will be something like the following:

So next step is just switch your workspace to the branch and start working on it. What does it mean? Well, tell your SCM that the changes you're going to make to fix the code have to go to the branch you've just created. It's not a big deal either!

Now it's the time of doing some real coding, making changes on your code to fix a given bug or issue. Not hard to do using Visual Studio 2010 (ok, or extremely hard depending on the specific bug!).

Visual Studio (from long time ago) comes with the pending checkins perspective to communicate with your version control and find what you've changed. In my example I've just modified a single file and I'm ready to commit it (and even added a meaningful comment to the change).

If you go back to inspecting your repository after your initial commit you'll see something like the following:

A couple of interesting things: first there's a new changeset on your branch and your changeset is not replicated (look at the replication source property on the right).

You can do very useful things like inspect the changes you've just made which is one of the good reasons of having your own version control on your laptop!

You can now easily repeat the process to work on different bug fixes, all starting from a well-known point, creating a branch for each of them.

Send your changes to the central server

You've been working for a while and you've already fixed a couple of bugs, so it's time to send your changes back to the central server. Hook up to your VPN and then push your changes.

In order to do so: the sequence of steps will vary depending on the SCM of choice. In case you're using Plastic SCM you can do it from the branch explorer within Visual Studio, simply select the branch you want to push, right click on it and say "push".

And you're done! Repeat the process for every branch you want to submit.

Getting remote changes

Getting remote changesets from the central server is also pretty straightforward. You'll have to repeat the steps you've completed when setting up your repository but this time instead of getting the entire branch it will only find what's have been modified since the last clone! Faster and easier.

Wrapping up

It's been a pretty fast step by step tutorial but I think I've covered the major concepts involved in replication and even some examples on how to achieve it with a specific tool, all within your beloved Visual Studio and without typing a single command!

We’re happy to report that highly awaited and much discussed Unity iPhone 1.6 has been released and is available for download. Yes, it’s exactly that mysterious build that adds generics support, enables multiplayer for iPhone and noticeably shrinks final binary size. You might have seen some trackbacks on Unity forums. So what’s so good about it? Now imagine [...]

I haven't had much time for blogging recently, too much exciting work going on at OsmocomBB:

• we now have simplistic support for Uplink (transmit) on SDCCH/4
• we have a minimal Layer2 (LAPDm) implementation
• we can send LOCATION UPDATING REQUEST to the network, and receive the respective response
• there's wireshark integration, i.e. all packets on the L1-L2 interface can be sent into wireshark for protocol analysis

There are still many limitations, but this is a major milestone in the project: We have working bi-directional communication from the phone to the network!

The limitations include:

• The cell has to use a combined CCCH (SDCCH/4 on timeslot 0)
• The cell has to use no encryption/authentication
• The layer2 is not finished, especially re-transmissions will not work yet
• There's no power control loop yet
• There's no timing advance correction

However, most of those are more or less simple we know what needs to be done, its just a matter of getting it done kind of tasks. There are no big unknowns involved, and particularly no further reverse-engineering of the hardware is required.

Also, the existence of a stable bi-directional communications channel between the network and the phone means that anyone interested in working on the higher layers can now actually do so. Completing and testing layer2 as well as RR/MM/CC on layer3 is a major task in itself, and it definitely requires the lower layers to be there.

The other good part is that development of layer2 and layer3 can happen entirely on the host PC, where debugging is much easier and there's no need for cross-compilation and we can use all the usual debugging options (gdb, valgrind, ...)

I'm now almost heading off for holidays (starting March 10), so don't expect any major progress from me anytime soon. I hope other interested developers will be able to take it from here and fill in some missing gaps until I'll get back.

Le mois de Février est déjà terminé, c'est le moment du résumé des activités.

Actualités

Voici une sélection de brèves glanées sur la toile :

• Neophysis [Armeniacum] est une nouvelle distribution basée sur oFono et FSO
• Une version "expérimentale" de QtMoko (branche V18) a été publiée
• Le SHR User Manual a été mis à jour pour la dernière SHR unstable
• Une Openmobility konference se prépare en république Tchèque mais la date n'est pas encore fixée
• Un Freerunner s'envolera vers l'espace pour la seconde fois
• Vidéo de SHR sur un HTC Dream (G1)
• Vidéo d'une voiture télécommandée par un Neo à l'Université de Bretagne Sud
• Une SHR Party mondiale se prépare pour fêter l'arrivée de la version Stable
• Qi-Hardware lance le Ben NanoNote, son premier MiniPC/PDA 100% opensource

Consultez également les dernières pages Community Updates (voir celle du 01/03/2010) pour plus d'informations.

Neuf billets ont été publiés sur le blog en février.

Au rayon des distributions,nous avons eus une nouvelle version de Android et de QtMoko. ainsi que la fusion de Moblin et Maemo pour donner naissance à MeeGo.

Le monde du Libre poursuit son expansion dans le domaine de la téléphonie avec la publication des sources de Symbian et surtout la naissance du projet OsmocomBB.

A noter également la mise à jour logicielle du WikiReader, l'apparition du Neo Freerunner A7+ et un retour sur le FOSDEM 2010.

Le forum garde une activité soutenue avec à ce jour :

• 588 inscrits
• 1176 messages
• 13557 discussions

Souhaitons la bienvenue à : fifou3101, lugarbleiz, leon, koocotte, cedric49fr, The Marauder, Scorate, kyrilkarlier et Airon90.

Voici une sélection non-exhaustive des nombreuses discussions du mois.

Communauté :

• Fosdem 2010
• Operation Solutions Linux

Logiciels :

• A quand Symbian sur le FR ?
• Petite question ...
• [QTmoko] V19 out
• [Android] version 0.2
• [SHR] utilisable ?
• MeeGo
• Une nouvelle distribution, neophysis
• Installation de u-boot boiteuse sur le NAND [Résolu]
• Kmoko ?

Matériels :

• Problème de microphone pendant les appels
• branchement d'interfaces extérieurs
• Achat FR A7+DB

Projets :

• [rendering] Automatisation

Divers :

• Proposition de stage: hackable:1 chez Bearstech

Bonne lecture !

Nous avons 2 nouvelles pages ce mois-ci :

• Téléphonie - Régler le son‎ : quelques solutions pour améliorer / bidouiller les réglages audio du Neo Freerunner
• 2010-03-16 : Solutions Linux‎ : préparation du salon Solution Linux qui se tiendra à Paris dans 2 semaines

Les pages suivantes ont également été mises à jour :

• WikiReader‎
• Compiler SHR‎
• Debian‎

Je rappelle que ce wiki est ouvert à tous et que les contributions sont vivement encouragées car c'est un bon moyen de capitaliser les connaissances.

Statistiques du site

• Graphique des visites :
  (on constate une légère baisse générale en février)

• Nombre de visites par mois :

(Cliquez sur l'image pour l'agrandir)

• Répartition par pays :

• Visites par jour :

Remarque : pour les graphiques suivants, j'ai dû changer les échelles pour améliorer la lisibilité.
Les chiffres seront donc donnés à partir de juillet (mois anniversaire du forum).

• Statistiques du forum :

• Les statistiques du wiki :

Bilan

Je suis toujours émerveillé de voir les idées originales certains sont capables d'imaginer autour du Neo Freerunner.
La rubrique Actualités ci-dessus en contient deux bons exemples : une voiture télécommandée par un Neo et un Neo expédié dans l'espace avec un fusée !
Ce genre de cas rappellent une nouvelle fois tout l'intérêt d'une plate-forme ouverte tant au niveau logiciel qu'au niveau matériel.

Enfin vous avez sûrement remarqué la préparation d'une SHR Party mondiale pour fêter comme il se doit la très attendue version Stable de la distribution SHR.
Sur la page wiki, elle est annoncée pour Mars 2010 !
Mais vous connaissez la rengaine du Libre : ça sortira ... quand ça sera prêt !
Alors comme on dit outre-manche : Wait and See ...

The biggest lump of code I've contributed to Mono, the Mono.GetOptions library is now being erased from the project.

It wasn't perfect and it's successor Mono.Options is a very capable replacement even if it doesn't do all the tricks Mono.GetOptions did in its prime.

Mono.Options is friendly to C# 3.0 features like lambdas, which allows writing code as terse as Mono.GetOptions allowed without using reflection and being a somewhat large dependency, the two main gripes Miguel had with my little library.

The last of Miguel gripes was about versioning (keeping more than one version in the fold) as some of the needed fixes and planned evolutions for Mono.GetOptions would mean breaking changes, which are better handled by consumers of the library by having distinct major versions with its separate APIs and attached series of minor releases.

That gets even more complex as you consider that Mono.GetOptions evolution also was tied to Mono releases.

If memory doesn't fail me, it was Mono.GetOptions and also other libraries imported into the project like SharpZipLib (which is still a problem as Mono is carrying two versions of it, and in this general cleanup process it is going over now we are trying to get rid of at least one of them), that prompted Miguel to change policy and ask for most non core libraries to be developed and released independently from Mono, even if developed by Mono hackers or used in some Mono utility. Better a package dependency (a soft one if possible) than the maintenance burden of embedded libraries.

Well let me quit reminiscing. Farewell my kid...

But if you are a loyal user of Mono.GetOptions what should you do?
You can:

1. Migrate to Mono.Options (or even use it's code directly as Miguel advocated some time ago because it is a lot slimmer than my library).
2. You can keep a copy of a Mono.GetOptions binary around to distribute with your solution (not an option for open source projects that would like to be accepted into Debian/Ubuntu).
3. Tell me you would like to see Commons.GetOptions, my own fork of it, get on the air and fly high. Version 1.0 of it has just the namespace change in it, so your migration effort would be minimal. See the Managed Commons group for more information.

Have nice developments