Re: [Community] OpenPhoenux Logo contest - Phase 2 (voting)

2013-01-15 Thread Thamos
Hi all,
I voted for 5, 7, 8 and 10. I liked nearly all logos, so i did choose by
exclusion. 1 and 3 where nice eye-catchers, but i didn't find much
relation to the project. Second may be a nice backround picture, but i
think it's not scaleable at all. Number for droped out because of
scalability, too. The sixth i liked, but i find it too nerdlike, reminds
me somehow of startrek... Number 9 dropped out because i don't see a
direct connection with the tux. This project is about free hardware, not
software (despite the fact that we need software, too...)  Proposal 11 i
can't connect to the project well, too.

Number five i choose because of its eye-catcher abilities. For scaling
small one may have to use the phoenix alone, without the device and the
whirls underneath. Number 7 i liked because auf it's simplicity. But i
don't know, if i have seen something like that already somewhere. I
think proposal 8 does connect at best with our devices. Maybe the broken
chain should be symbolised a little bit more clear. The 11th i chose
because it connects well to the fact that its about a hardware project,
the symbol alone is nice to use at small scales and i haven't seen much
symbols like that already (high recognizability)

so far, my 2 cents...

Am 14.01.2013 17:53, schrieb Dr. H. Nikolaus Schaller:
 Hi all,
 we are currently running a logo contest for the new OpenPhoenux
 umbrella project that intends to cover all old and new openmoko
 We have received 11 proposals (and sometimes variants).
 You can now participate by judging the proposals. Please think about:
   • does it connect to the remains of the original Openmoko project 
 (Phoenix from the ashes)?
   • is it eye-catching, easily remembered, unique?
   • does it show some orientation towards future?
   • does it carry a positive, inpiring, flying, pushing attitude?
   • does it tell about freedom  openness?
   • do you feel that it represents your OpenPhoenux/OpenMoko community?
   • can it be recognized that it has something to do with wireless, 
 portable devices (tablet, smartphone, gadgets etc.)?
   • does it look equally good in different sizes?
 Now please see yourself and submit your votes (up to 4 favourites):
 Please vote until Tuesday evening (15th Jan 2013, GMT).
 You may also discuss pros and cons as a followup to this mail.
 Openmoko community mailing list

Openmoko community mailing list

Re: Ubuntu / Firefox OS for Openmoko

2013-01-11 Thread Thamos

i am ambiguous about that.
I think we have already enough Operating Systems with QtMoko and SHR and
Replicant. (Did i miss a really working distro?)
But, as it seems to me, we don't have enough software developers, and as
Mozilla and Ubuntu are big projects, this seems to be a way to use their
ressources to get some nice features to our phones.

i don't know anything about the OSs themself to evaluate them.
And i don't know if they are really interested in working with us, as
you wrote, they are searching big players

I think the question is if we have people on our side who want to start
such an project (and try to drag some of their developers in).


Am 11.01.2013 11:38, schrieb Christoph Pulster:
 I am interested what you think about Ubuntu Smartphone version and  
 Firefix OS in combination with Openmoko hardware.
 As far as I understand, both are looking for a big player in the  
 smartphone hardware market to establish their software platform on the  
 mobile market.
 Wouldnt be the combination of open source hardware in shape of Openmoko  
 (GTA04 !) and open soruce software a nice idea ?
 Openmoko community mailing list

Openmoko community mailing list

Re: About the future of the middleware

2012-07-24 Thread Thamos
Thanks a lot, you'r the greatest :)

Am 24.07.2012 18:17, schrieb Simon Busch:
 Am 24.07.2012 11:27, schrieb Thomas Munker:
 i thought the ui is saving the volume values where it should (using
 opreference interface), but fso doesn't pick them up. There's an old
 bugreport in shr-track [0], that suggests it's fso's fault. Maybe this
 should be clarified. I've found a new bugreport too... [1] And it's been
 for some years in the fso-track, too: [2]
 Ok, will look into this bug reports.
 With the network-registration, i get alwas an error that this feature is
 not implemented for my modem. Maybe shr uses to old feeds of fso, i
 don't know.
 Hm, you're right. I got it wrong cause looking at the wrong place in the
 source code :) Sorry for that. I will implement this really soon.

Openmoko community mailing list

Re: About the future of the middleware

2012-07-21 Thread Thamos
Hi all.
I've never seen someone using the conference-feature. I think selecting
the provider is more important. (this one really annoys me, since i am
near an border and simply can't phone until i get out auf alien range,
if the phone switched one time, even reboot doesn't help...). I also
miss the possibility to choose loudness of the ringtone reasonably. Most
other phones are even able to choose a ringtone based of the caller!

Apart from that i comply with you.

kind regards,

Am 21.07.2012 20:45, schrieb Simon Busch:
 Hey everybody,
 as a lot of you may have noticed we did two releases in the past months
 of the FSO stack. Both were related to bring stability and consistence
 to the stack. Now I want to talk with you about the future of the stack.
 In the past we were only concentrating on getting new hardware supported
 and lost our real focus on creating a middleware suitable for
 embedded/specific-purpose devices. This is where I want to go back to
 and get into development again.
 In the last weeks I looked over several parts we have in our stack and
 tried to find out where we can improve and get into development of new
 features again. A lot of you have stability in mind as you want to use
 something with FSO on your daily phone. Thats the second peace which
 should be part of the core development focus of the
 Getting new features is fast said but I have several things on my list
 where I want to improve FSO in the next weeks and months. Everything is
 focused on the core stack which is formed by our framework libraries and
 the three daemons fsodeviced, fsogsmd and fsousaged. We have other
 daemons like fsotdld as well but that will be not on my focus. If
 someone wants to step up with further development of these just go on
 and get in contact. But please don't get me wrong: I will support all
 other daemons like fsoaudiod and fsotdld in the next releases too but
 just not doing any development related work for them.
 For fsogsmd there are the following things on my list:
 1. Get the last peaces of not implemented things in like conference or
 emergency calls
 2. Several API cleanups
 3. Get several bugs fixed
 4. Do integration testing with a remote controlled phonesim so we can
 simulate incoming calls etc. This will also included integration testing
 with a remote controlled fsogsmd on another device
 5. Multi device support: While working in HFP HF support in fsogsmd I
 discovered that things would be easier if we can control more than one
 modem with the same daemon at the same time. Think about phone with
 support for more than one SIM card. Work has already started for this in
 the morphis/multi-device branch of the cornucopia repository.
 6. Cleanup of the modem status handling: right now the modem status and
 SIM/network status are too much tight together. We have cleanly separate
 7. Internally we don't separate a modem from a AT based modem; that
 needs to be fixed
 8. A lock-down mechanism to keep anyone out when doing a firmware
 upgrade. When doing a firmware upgrade of a modem we have the problem
 that nobody should access the modem while this is in progress. The idea
 is now to implement a dbus API to lock the modem by requesting a lock
 and only the requesting program can unlock the modem again. While the
 modem is locked nobody else can access the modem via fsogsmd.
 - nothing right now
 - nothing right now
 - I am thinking about grouping all libraries together so just have one
 single framework library and don't need to maintain several small
 libraries which increases the complexity of release testing, ABI
 refinements, etc. Just one libfsoframework; this is only a thought in my
 head right and nothing concrete.
 That are some of my toughs were I want to go with FSO in the next
 months. So no focus on concrete devices but getting the stack itself
 forward to be ready for every kind of a device.
 I would be really happy to hear what other people are thinking about the
 idea behind FSO since it was started back in 2008. What are your missing
 features? What do you like and what not?

Openmoko community mailing list