Re: ``Freerunner reliable and stable''?!
2008/10/26 Matthias Apitz [EMAIL PROTECTED]: I'm a bit tired of all those (useless) threads like this. I DO USE the FR with Om2008.9 for everyday use, I do not even own any other cellphone. We should improve what we have and stop useless discussions, as well about Google's trick of Android which has nothing todo with free software. Same here. The stability is sufficient for daily use. It is not as stable as my previous or antepenultimate phones, but those were quite simple, unable to do more than make calls. The only issues I have with the Freerunner are battery life and an occasional (one call per week, roughly) lack of sound. Neither is sufficient to cause me to switch back to my previous phone. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New Rasterman Image...
2008/10/1 The Rasterman Carsten Haitzler [EMAIL PROTECTED]: eg: Press | Guess+dist e e+0 w+1 r+2 d+2 s+1 r r+0 t+1 e+2 f+1 g+2 d+3 k k+0 l+1 o+2 i+3 j+3 d d+0 f+1 s+1 e+1 c+1 r+2 w+2 I assume this takes into account the keyboard layout, so if I use dvorak or some random layout, it'll do the right thing. Right? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ASU - out of memory?
2008/8/22 Tilman Baumann [EMAIL PROTECTED]: Pardon. I don't care for the warm and fuzzy feeling you get by having malloc fail on you. It does not give you a bit more system stability! The one app receiving malloc errors is just not app of many. They all have a problem then. Imagine, the browser catches a failed malloc, because some other stupid app has eaten almost all ram. What is the benefit of telling the browser about low mem? It could only safe itself from crashing. Well done. Imagine that malloc() returns null rather than overcommitting. Most affected apps will receive a SIGSEGV when malloc returns null because there's no error handling for that situation. Some will notice that malloc() returned null and either forgo some optional stuff or abort a single operation or simply just shut down gracefully. Imagine that malloc() returns an invalid pointer when it overcommits. All affected apps will receive a SIGSEGV in this case, without some unusual error checking. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ASU - out of memory?
2008/8/22 Chris Wright [EMAIL PROTECTED]:
2008/8/22 Tilman Baumann [EMAIL PROTECTED]:
Pardon.
I don't care for the warm and fuzzy feeling you get by having malloc
fail on you.
It does not give you a bit more system stability! The one app
receiving malloc errors is just not app of many. They all have a
problem then.
Imagine, the browser catches a failed malloc, because some other
stupid app has eaten almost all ram.
What is the benefit of telling the browser about low mem? It could
only safe itself from crashing. Well done.
Imagine that malloc() returns null rather than overcommitting.
Most affected apps will receive a SIGSEGV when malloc returns null
because there's no error handling for that situation.
Some will notice that malloc() returned null and either forgo some
optional stuff or abort a single operation or simply just shut down
gracefully.
On the other hand, let's say your process allocates some memory and
doesn't use it for a while. In the meantime, some memory is freed.
This doesn't help if malloc() returned null, but it does help if the
kernel overcommitted memory instead.
I don't think that's as useful. But you could instead define a malloc:
void* _malloc(size_t length)
{
void* pointer = malloc(length);
if (!mlock(pointer, length)) return null; // or abort
return pointer;
}
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: Emergency call at boot time functionality (was Re: Windows CE on freerunner)
2008/8/22 Lothar Behrens [EMAIL PROTECTED]: You must have a lock, since otherwise you may accidantly issue an emergency call. Lothar With my current phone, you can make emergency calls on it, even if the phone is locked. It happened to me once. I got a call a few minutes later from the call center asking if everything was okay. I'd rather not repeat that. Locks that do not allow emergency calls are good. Especially considering that you need to take various other steps to place an emergency call with the Freerunner (go to an application menu, choose an icon, dial). ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: atd: how to start a job every 10 minutes ?
2008/8/15 Harald Koenig [EMAIL PROTECTED]: On Aug 15, Roland Mas wrote: You may want ot look at cron instead of at. at is for one-time jobs, cron is for recurring jobs. will cron work while FR being suspended ? haven't checked yet, but so far I've read this only from atd, and atd exclusively opens /dev/rtc (see hwclock problems...) bute maybe there is a OM cron version which interfaces with atd ?! I'll check, thanks for the pointer... If not, then you can write a script that executes whatever you want and then adds itself to atd. -- Those who do not understand recursion are doomed. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: FSO: is zhone here to stay?
2008/8/7 Stefan Schmidt [EMAIL PROTECTED]: On Thu, 2008-08-07 at 12:39, Craig B. Allen wrote: If zhone is going to be around for a while, how can I make a request for a new feature? Well, that depends a lot on what kind of feature request this is. As I wrote above, zhone is mostly to test our APIs and implementations. It's not targeted to fullfill all user needs yet. Basic phone functionality is the goal. If it is something in this area feel free to submit a ticket for it: http://trac.freesmartphone.org I take it you'd accept patches to add features to zhone, even if they're unrelated to the framework, no? regards Stefan Schmidt ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: any update on GSM interference issue
http://gadgets.boingboing.net/2008/08/02/kill-gsm-radio-buzz.html Maybe that could provide a less invasive means to getting rid of the problem? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko on Design
2008/7/29 Marek Lindner [EMAIL PROTECTED]: Hi, At the same time we heard comments from a key developer who indicated that the decision was made above him by unnamed individuals with whom the community has no obvious means of communication, and who apparently don't even listen to the reasonable technical arguments of key developers. Openmoko always avoided all kind of formal structures. Thus we don't have such a thing as key or core developer - a developer would be better. But you do have a design team, according to Rasterman. This also seemed to reveal something about the internals of Openmoko that weren't expected: development decisions are not entirely made by the developers, but instead they answer to some people who the community cannot readily identify and who the community doesn't know how to interact with or if they even can interact with these decision-makers. May be it revealed that Openmoko itself is diverse as well. That some developers have different opinions than others. Out of curiosity, how many of these developers use an Openmoko phone as their primary phone? Do these differences of opinion tend to fall on the same boundaries? Still, nobody has mentioned why the design team can't be contacted or identified. Openmoko has to trust those members of the community, who prove themselves through actual contributions, to be worthy to give input on larger design issues as well. You got the point ! Strange, I read this as Openmoko has not been, but should in the future, trust those members I haven't been here long enough to determine which is the case. Maybe the company hasn't, either. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko on Design
2008/7/29 Marek Lindner [EMAIL PROTECTED]: On Tuesday, 29. July 2008 20:17:00 Chris Wright wrote: But you do have a design team, according to Rasterman. Of course we have. How do you think we are trying to get to a device that is ready for end user ? And this is just the beginning. We will work with more designers for the UI, the housing, etc to continue the direction towards the mass market. But that does not mean all that is perfect right from the beginning or that we don't listen to constructive criticism. Please help us making it better by _demonstrating_ a superior solution not by sending more emails. Where I work, the design team is the same as the development team. Out of curiosity, how many of these developers use an Openmoko phone as their primary phone? What do you mean with these developers ? Everybody certainly has a different opinion than others on something. Then it's vacuous to say so. Do these differences of opinion tend to fall on the same boundaries? I don't get what you trying to say here. Something as simple as a keyboard button -- well, users were complaining about its lack very quickly. If the design team were also users, then they would have insisted that the error be fixed. Still, nobody has mentioned why the design team can't be contacted or identified. Sorry but this is just not true. I don't get why you follow this childish witch-hunt game. Because you were responding to this quote: This also seemed to reveal something about the internals of Openmoko that weren't expected: development decisions are not entirely made by the developers, but instead they answer to some people who the community cannot readily identify and who the community doesn't know how to interact with or if they even can interact with these decision-makers. And your response was in no way related. I was merely pointing that out. Strange, I read this as Openmoko has not been, but should in the future, trust those members I haven't been here long enough to determine which is the case. Maybe the company hasn't, either. Meant was: Openmoko pays much more attention to installable solutions and listens to hackers that provide those instead to people that complain all day long but don't get their hands dirty. Okay. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Alternative stylus - Group Buy
2008/7/19 Steven ** [EMAIL PROTECTED]: Anyone interested in a different group buy? I want one of these: http://www.jetmall.net/index.asp?PageAction=VIEWPRODProdID=303 I'm with you, too. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Rules based policy engine
2008/7/20 Ryan Meador [EMAIL PROTECTED]: I think it's important that we use an existing general-purpose platform such as Prolog (at least, it's about as general purpose as logic programming gets...). I would favor Rhino.DSL, simply because I know it integrates well with a language with dbus bindings. And because it can probably result in very readable syntax. And it's based on Boo, which is very nearly Python, and thus more accessible to most programmers than Prolog. Does dbus allow you to specify your priority when listening to an event, and to prevent it from being published to other listeners? If not, then the first step is to separate the relevant dbus events and come up with an application that merely translates unconditionally between the two. And that allows you to insert any rules engine you want. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: openmoko availability from the online store, set opening time if not date?
2008/7/2 Crane, Matthew [EMAIL PROTECTED]: Maybe you guys could set a time that the web store will open, on whatever day it does open? E.g. if it's not open by 10am, it's not going to open that day. That could give everybody a fair shot of getting their orders asap. Matt Or at least don't bother checking for the next ten hours/three days/whatever. Information ish good. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QVGA V/s VGA for GTA03 (was something about yummy CPU-GPU combos!)
2008/6/10 The Rasterman Carsten Haitzler [EMAIL PROTECTED]: On Tue, 10 Jun 2008 16:40:08 +0100 Stroller [EMAIL PROTECTED] babbled: On 10 Jun 2008, at 02:17, Carsten Haitzler (The Rasterman) wrote: browsing full web pages scrammed into a 2.8 screen as many have suggested, is really... pushing such a tiny screen far beyond its usefulness. web pages are designed for 14 or 17 screens or so. squeezing them down into 2.8 is nigh madness. it's possible - but vga vs qvga there isn't the factor (imho) :) I'm sorry, Carsten, but this just makes me think you're nuts. Um, I mean, eccentric. I mean, I know you know loads more about this sort of thing than I do, but mobile phone web-browsers are absolutely standard these days. never said otherwise but the screen is physically small. very. put it at a normal usage distance and it covers a small fraction of the field of view a standard desktop screen does. web pages are normally designed for the field of view of a desktop screen. either you play zooming games to squeeze it down, or scrolling, or play re-formatting games. however you look at it - you won't get close to the same experience. True...someone mentioned a month view for a calendar with a meaningful amount of content as a use case for a higher resolution screen, but on a three-inch display, you're not getting any significant amount of data across without a magnifying glass. Using a terminal emulator would be far more pleasant with the higher resolution screen, but you're not going to get an 80x25 window in there; with a 640x480 display plus an on-screen keyboard, you're going to have either an 80x30 or so window in portrait mode and an unreadable font, or you're going to get about 80x15 in landscape. Video's going to scale anyway (which says more about processor / gpu issues than about acceptable quality). Really, viewing photos is the only thing that will suffer significantly. This isn't as much of an issue since the Freerunner doesn't have a camera. But the GTA04 probably will, and the QVGA might be somewhat annoying. Since the alternative to using QVGA is using VGA with a faster GPU and processor, and this is a phone that runs on batteries, I'm inclined to encourage the use of QVGA on future Openmoko phones. I have a phone from 2002 with a battery that used to last a week; it annoys me to deal with much less than that. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QVGA V/s VGA for GTA03 (was something about yummy CPU-GPU combos!)
2008/6/13 enaut [EMAIL PROTECTED]: I'm feeling reminded of those creditcard sized poket calendars we have in germany. on those you have got the calendar information of a whole year + the Information of hollidays and other special days. land everything is readable and pretty clear to read. so the size is not the problem. but rather the resollution as well as the clearness of the display. Those include no more text than numbers for the date. Which you can do with qvga as well, I am certain, if it's one month. And you can also include colors to indicate there's an event on that day, or it's a holiday, or whatnot -- none of which requires a larger display. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Why not use votation system?
2008/6/12 Brad Midgley [EMAIL PROTECTED]: Michele Do you want feature X or feature Y? you might need a table representing the cost and business feasibility of each feature. We've seen a lot more transparency on the 3g decision recently which reveals it to be more complicated than people thought. I have some notes here on the knapsack problem, if we go that route ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GTA03 case should incorporate stylus holder
2008/6/6 steve [EMAIL PROTECTED]: Stroller you crack me up. (vi rules.) We need a religious war between the Digitii, the Stylii, and Quertii. Or three products? Rant away. Your views are always welcome. What of the Dvoraksai? I do think that thumb keyboards are best -- tactile feedback. Finding space for such is not terribly easy. There are clamshell designs, though that prevents you from using the primary display without opening the device; then there are sliding designs, which seem to have a bad angle. Thumb typing on a touchscreen is probably more efficient than using a stylus. Thumb typing on a keyboard is probably much faster than using a touchscreen. Though if people want a stylus holder, how hard would it be to design one that clips onto a Freerunner? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QVGA V/s VGA for GTA03 (was something about yummy CPU-GPU combos!)
2008/6/9 Dotan Cohen [EMAIL PROTECTED]: 2008/6/9 The Rasterman Carsten Haitzler [EMAIL PROTECTED]: an 80x24 terminal is possible to make it readable @ qvga - if we allow scrolling. (and possible in landscape with an ultra-tiny 4-pixel wide font - possible (3 pixels for text, 1 for space). not very nice though. That is unusable. I'm sorry, I will not force myself to use that. I will buy something else. Using the terminal on a remote machine with a 4 pixels font is possibile like it is possible to eat cockroaches for lunch everyday. There are some 'can get by' that I will not force myself to get by with. The same with having to flip between right/left panes: it turns a half-second operation into a five-second one, and it taxes the brain at the same time. Moreover, this has to fit a keyboard along with anything else. The keyboard itself has very minimal needs in terms of resolution, but it steals about a third of the screen in portrait mode, more in landscape -- 640x480 is probably a bare minimum. You'd be getting 200 by 240 usable space with qvga. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
OT: ajax image galleries
2008/6/3 Marco Trevisan (Treviño) [EMAIL PROTECTED]: There are some pics and videos by Einstein from freeyourphone.de: - http://tinyurl.com/66ktzl (URL maps to http://freeyourphone.de/portal_v1/gallery/menu.php?gallery=membersalbum_id=8 ) Those AJAX image widgets seem to be designed adversarially. They prevent tabbed browsing of images, make it difficult to link to an image, impose additional delays on the viewer, and introduce a new UI for navigating the galleries that doesn't fit in with any existing browser. Viewing a large image and then a small one requires additional scrolling, unlike any non-ajax solutions I've seen. The one that that link goes to allows you to click on the right half of the image to go to the next image or the left half of the image to go to the previous, with no visual clues that that is what is happening. Do they have any recognizable merit whatsoever? Why do people use them? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Yummy new CPU/GPU combo
The cost is probably on the order of paraplegia. And I wonder about the power requirements -- there haven't been significant advances in battery technology lately. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Open Hardware
Openmoko phones are as cheap as they are because they use commodity hardware, I'm given to understand. If you wanted a phone with open hardware, you'd probably be paying thousands for all the custom components. Plus there's testing and certification for various parts, which probably is also expensive It's doable, but it'd be harder by far than the OGP. And consider that the first card released by the OGP costs $1500, which is two or three times the cost of the more expensive commodity cards, while delivering less performance (their target is 20fps in Quake 3 at 1280x1024). ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Library can handle MP3 id3tag encoding
2008/5/27 Bin Chen [EMAIL PROTECTED]: HI, Is there a good library can handle MP3 id3tag encoding easily? AFAIK, the encoding that in the id3tag can't be decided, it maybe ASCII, UTF-8 and others which sometimes cause the software to decode some error character. The libid3tag can do raw reading to id3tag but not handle the encoding easily. You need one library to read the tag's text fields as raw byte arrays and another to determine the encoding. The latter is highly nontrivial. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Switch from GTK to QT (was: ASU software - pre-pre-release impressions)
2008/5/21 Nkoli [EMAIL PROTECTED]: On Tue, May 20, 2008 at 1:32 PM, Carlo E. Prelz [EMAIL PROTECTED] wrote: My complaint is that it would be difficult for me to put my hands into the default apps. They are C++, QT, and expectedly using enough of those creepy C++-isms (possibly, even those yecchy templates or whereabouts). I would be comfortable with tinkering with CGTK main apps. On the other hand, I would find C++QT main apps closed boxes (I perfectly know that I could very well write C/Ruby new code on the OM). From this statement, one would think that you don't use _any_ applications written in C++ or Qt for the simple reason that you can't tinker with the code. I am sure this is not the case. You use the applications written in C++/Qt and play with those written in the languages you're comfortable with or you write your own from scratch. Right now OM needs more new apps than it needs shipped apps taken apart (which will probably be done by a number of people anyway). In this case, openmoko is still being marketed to developers and is still alpha software. As such, I have a reasonable expectation that I will want to hack a fair number of the applications it ships with. So that is a valid complaint. Of course, you could simply rewrite each application in your preferred language, but that's a waste of effort. Or you could not mess with the applications written in a language you do not prefer. Or you could wait until there's a more severe need and then learn the language in question and start working on the application. With desktop Linux, most things are sufficiently mature that I expect not to have to hack them. So the language they are written in is far less important. Of course, one person's opinion doesn't matter much, as long as there are plenty of people familiar with the languages that are commonly used in openmoko. I think there are far more people who can effectively write C collaboratively than who can effectively write C++ collaboratively. The larger issue is extending a C++ codebase in another language. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ASU software - pre-pre-release impressions
2008/5/20 Ben Burdette [EMAIL PROTECTED]: Travis Tabbal wrote: C++ is difficult to link against, so that limits the languages that you can use for development. For instance, D has a hard time with linking to C++ (or did last I checked). C, on the other hand is far simpler to link to. That's why many standard APIs use C interfaces - OpenGL for instance. Recent versions of dmd can link against C++ code compiled with dmc, but it's a bit unreliable, from what I've heard. And D has *extremely good* support for linking with C++, compared with other languages. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Will GTK be used in Openmoko? (was: Re: Software Status Update)
2008/5/15 Flemming Richter Mikkelsen [EMAIL PROTECTED]: On 5/15/08, Geoff Ruscoe [EMAIL PROTECTED] wrote: I think gtk should definitely be part of the platform. As far as I know the Java Swing hooks are for gtk. Since its shipping with Java it should be able to use the gtk, right? Plus as far as I can tell the ruby and python hooks for gtk are slightly cleaner and easier than working with qt. So from a developer standpoint I think we're better off with gtk. Thoughts? Qt and GTK is the only options. GTK has the best license _and_ is very easy. GTK has a lot of bindings and is very crossplatform. Considering that Rasterman is working with openmoko, I'd be surprised if ewt were not an option. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Root password and ssh?
2008/5/14 Mo Abrahams [EMAIL PROTECTED]: Except for if music files, images etc. on the phone are owned by root, in which case we wouldn't be able to access them via ssh. On the contrary! 1. Disable root login via ssh. 2. Log in as a luser. 3. Su to root. -- http://dsource.org/projects/dmocks -- Mock objects and more for the D programming language ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
