> Dear all
>
> We are very happy to introduce the new fon development community
> program: the fonosfera.
>

> You all have demonstrated that the foneras are able to do much more than
> what they currently do. You, the development communities, have fixed
> many bugs, added features and improved the functioning of the fonera and
> so, we would like to give you the opportunity to keep doing this great
> work. This is why we have decided to launch our latest product, the
> fonera 2.0, under the umbrella of a new development framework, the
> fonosfera.
>
> The idea behind the fonosfera is to open a channel so all the

> development work the communities have been doing and will do in the
> future, can reach any fon user in a simple way. We want the communities
> to keep their autonomy and don’t want to merge them all into one. We
> know you already have your own members, your rules and your methodology:
> we don’t want to change that. Doing so, we expect you will be encouraged
> to work happier and more motivated in new developments. We will try to
> make things easy for you and give you all the credit for your work.
>
> As so, the fonosfera will be not much more than a space for gathering
> and sharing with other developers and offeri

ng your work to end users
> all around the world. It will be a framework where you will find
> development and community tools such as svn, trac, forums, mailing list,
> wiki etc. This is something we would like to define with you all. In
> order to do so, you have selected 1 member of each of your communities
> to act as a contact point. These people will have direct contact with
> the fon team in charge of the fonosfera project. They will receive our
> notifications and will be in charge of giving us the impressions,
> decisions, comments and feedback of their corresponding communities.

>
> Currently, we are setting up the source code of the fonera 2.0 which
> basically consist on the source of the fonera+ (so you can already work
> with it) plus some additional parts that are very interesting:
>
> * NTFS-3g driver: this driver was available long ago for but it
> didn’t work for big endian mips devices (as the fonera is). We
> sponsored the porting and testing of it. It

is already available
> to download at the official page, but we will also include it in
> the source tree we will provide you.
> * Some controls for hard drives in the web interface. We have done a
> reduced web tool to manage the hard drive from webif.
> * HSDPA connectivity scripts (still under development)
> * New wifi driver binary: it’s still under testing but seems to be
> much better.
> * And more
>
> Our goal is to make this new device a success. Because this will mean
> that many more foneras will be available for connection around the
> world. We want the fonera to be a useful device at home so they are
> online 24h a day. This will improve the quality and size of the fon network.
>
> To achieve this, we have set

up a development flowchart. It basically

> defines how things should be done to get the most efficient, secure and
> flexible development framework. There are some limitations that fon as a
> company has and sometimes you will have to understand that, but we don’t
> think they will have much impact on the project.
>
> The summary for this development rules is basically:
>
> * you will have 100% freedom to develop what you want to
> * all packages/development eligible to be *official* fonosfera
> packages, will have to be tested in a trustful way by the community
> * fon will try to make all packages official, as long as they don’t
> go against our interests or potentially harm the users (owners or
> visitors) or have legal issues
> * the packages should be organ

ized so that there are no conflicts
> between them and even less with fon’s minimal functionalities
>
> This is just a list summarizing the conditio

ns, but you can see they are
> more than reasonable. For more detail, please wait until we have
> contacted with your representatives. They will explain all the project
> to you and will of course accept your suggestions and hand them to us.
>
> You will soon receive your corresponding fonera 2.0 if you didn’t yet.
> We hope you will enjoy using it and working on it. You have full access
> to it and of course, we are eager to help you.
>
> The devices you received do not have the latest firmware, because they
> were produced about 6 months ago. So you will probably need to reflash
> them with the latest firmware or one of your own.

The source code we

> will provide you will be newer, but soon, we expect to merge with the
> latest OpenWrt trunk, and this will be the base for the future fonera
> 2.0, when it reaches the market.
>
> So, this is it. We are so happy that we finally took the step forward
> and we expect you will like this new fon-era. You will hear from us very
> soon again.
>

> Best,
>
> The firmware team and the fonosfera team at FON
>
>

> P.D.: find attached the logo of the fonosfera, both for black and white

> backgrounds (either can be used on coloured backgrounds)


root@salotto:/home/zarrelli# locales
Sorry, command-not-found has crashed! Please file a bug report at:
https://bugs.launchpad.net/ubuntu/+source/command-not-found
Please include the following information with the report:
unsupported locale setting
Traceback (most recent call last):
File "/usr/lib/command-not-found", line 19, in
parser = OptionParser(version = __version__, usage=_(”%prog [options] “))
File “/usr/lib/python2.5/gettext.py”, line 584, in lgettext
return ldgettext(_current_domain, message)
File “/usr/lib/python2.5/gettext.py”, line 556, in ldgettext
return t.lgettext(message)
File “/usr/lib/python2.5/gettext.py”, line 366, in lgettext
return tmsg.encode(locale.getpreferredencoding())
File “/usr/lib/python2.5/locale.py”, line 514, in getpreferredencoding
setlocale(LC_CTYPE, “”)
File “/usr/lib/python2.5/locale.py”, line 478, in setlocale
return _setlocale(category, locale)
Error: unsupported locale setting
Python version: 2.5.2 final 0
bash: locales: command not found
root@salotto:/home/zarrelli#


E son soddisfazioni anche queste. Accentuerei la soddisfazione, ma mi ci vuole un tot per trovare le accentate…

Version 2.0

The version originally planned as the first release, except for
a couple of data-eating bugs that just won’t seem to go away;
no free upgrades or the company would go bankrupt.

Versione 2.0

La versione originalmente pianificata come primo rilascio, eccetto
che per un paio di bug in grado di trangugiarsi i dati e che non sembrano
volersi togliere di torno; niente aggiornamenti gratuiti o l’azienda finisce
in bancarotta.

[Via GNU Jokes]

Jumping to a completely different subject, I learned something new this week about something old — the origin of the term “bug,” referring to a problem with computer hardware or software. The story I originally heard directly from the late Grace Hopper, the mother of COBOL, was that a malfunction in the Mark II computer at Harvard in 1947 was traced to a dead moth that in its last living act had shorted out a circuit card. They taped the moth carcass in the computer logbook and history was made. Only it wasn’t, as I realized this week while reading the 1932 Flying and Glider Manual published back then by Modern Mechanics magazine.

“Once you have built your sportplane,” wrote the editor, identified only as Andy, “it must be test flown. If you have already taken flying lessons, you can hop it yourself — if not, entrust the job to a competent pilot. He’ll put it through its paces and find out if there are any ‘bugs’ that need correcting before the plane goes into active service.”

So much for Grace Hopper’s version of the story.

It turns out that “bug” was a common term for hardware glitches and dates back to the 19th century and possibly before. Edison used the term in a letter he wrote in 1878. This is no earthshaking news, of course, but simply reminds me how self-centered we are as an industry and there really isn’t much that’s truly new.

Passando a un argomento completamente differente, questa settimana ho imparato qualcosa di nuovo su qualcosa di vecchio - l’origine del termine “bug” (baco, n.d.t.), che si riferisce a un problema relativo all’hardware o al software di un computer. La storia che ho ascoltato originalmente dalla Grace Hopper, la madre del COBOL, parlava di come un malfunzionamento del computer Mark II ad Harward nel 1947 fosse stato fatto risalire a una falena morta che, come ultimo atto da essere vivente, aveva cortocircuitato una scheda elettronica. La carcassa della falena era stata (quindi, n.d.t.) incollata con in nasto adesivo al diario dei log del computer e da qui viene fatta risalire la storia (n.d.t.). Solo che non è andata così, come ho avuto modo di accorgermi questa settimana, mentre leggevo il “Flying and Glider Manual”, pubblicato nel 1932 dalla rivista Modern Mechanics.

“Dopo avere costruito il vostro aeroplano”, scriveva il redattore, identificato solamente come Andy, “deve essere provato in volo. Se avete già preso qualche lezione di volo, potete saltarci dentro - altrimenti, affidate il lavoro a un pilota competente. Ne saggerà le caratteristiche e scoprirà se vi sono dei “bugs” (bachi, n.d.t.), che richiedono delle correzioni prima che l’aereo venga posto in servizio attivo”.

Questo per quanto riguarda la versione della storia di Grace Hopper.

Sembra che il termine “bug” fosse comunemente usato per guasti hardware e risale al 19 secolo e forse anche precedentemente. Edison utilizzò questo termine in una lettera che scrisse nel 1878 (parlando di bugs nei circuiti elettrici, vedi National Museum of American History). Non si tratta di notizie che sconvolgano il mondo, naturalmente, semplicemente mi ricordano di come la nostra industria sia auto centrica e come non vi sia molto di realmente nuovo.

[Via I,Cringley]