Maximum SDHC capacity supported?
Hi As there are some 8GB SDHC cards out there, are there limitations on the neo? (as soon as it's SDHC, shoudl'nt be it ok?) Florent ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Maximum SDHC capacity supported?
Florent THIERY wrote: Hi As there are some 8GB SDHC cards out there, are there limitations on the neo? (as soon as it's SDHC, shoudl'nt be it ok?) MicroSD, not SD. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: firefox for mobiles
David Ford wrote: If it's anything like mozilla/firefox now, we're gonna need a hefty battery, hugely more cpu, and about 1G of ram onboard. Oddly. It seems to behave OK on my laptop - 1.5 - which I was using for some time with 128M RAM. Admittedly, it did need restarted every day or three. The big problem is the lack of debug tools. I write a new extension. I then want to profile it, to find out how much CPU, and how much CPU it makes the core use. I can't. Worse, the same problem applies to most of the XUL/XBL/JS core. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Maximum SDHC capacity supported?
Hello. On Fri, 2007-05-11 at 11:41, Florent THIERY wrote: > > As there are some 8GB SDHC cards out there, are there limitations on > the neo? (as soon as it's SDHC, shoudl'nt be it ok?) MicroSD is up to 4GB right now. As SHDC starts from 4GB there should be no difference. The real problem is to buy such a card. Until now we were not able to find a source for them. A bug for testing is already open: http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=93 If anybody knows a source for this cards let us know. We are eager to buy and test. :) regards Stefan Schmidt signature.asc Description: Digital signature ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Maximum SDHC capacity supported?
Hello. On Fri, 2007-05-11 at 12:59, Carlo E. Prelz wrote: > > Quoting Stefan Schmidt ([EMAIL PROTECTED]): > > > If anybody knows a source for this cards let us know. We are eager to > > buy and test. :) > > A quick search on preisroboter.de with keywords 'microsd' and '4gb' > returns a number of merchants in germany, ready to take your money for > such a card, apparently. SanDisk is the producer, and the cheapest one > is sold at 74.89 euros including adapter for plain SD format and USB > reader. Having them in the webshop and being able to deliver seems to be some different things for some shops. It should be worth another try anyway. It some time since our last try. Thanks. regards Stefan Schmidt signature.asc Description: Digital signature ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Maximum SDHC capacity supported?
Subject: Re: Maximum SDHC capacity supported? Date: Fri 11 May 07 01:10:50PM +0200 Quoting Stefan Schmidt ([EMAIL PROTECTED]): > Having them in the webshop and being able to deliver seems to be some > different things for some shops. Yes... I looked at each shop. No-one has them in stock. One shop promises delivery in 4-6 workdays... Carlo -- * Se la Strada e la sua Virtu' non fossero state messe da parte, * K * Carlo E. Prelz - [EMAIL PROTECTED] che bisogno ci sarebbe * di parlare tanto di amore e di rettitudine? (Chuang-Tzu) ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
opera for mobiles
Right now I'm using Opera Mini on my Nokia6230, Opera Mini is J2ME based. It's not browser by conventional means as it uses some Opera-server for website customization and compression. As a Java Midlet it does not take up to much memory by any means - hence it's not as comfortable/convenient as any real browser ;-) Where Opera Mini comes for free, a more smartphone adapted version 'Opera Mobile' is commonly sold to smartphone manufactures. Opera Mini: http://mini.opera.com Java-Applet-Simulator: http://www.operamini.com/demo/ Opera for devices: http://en.wikipedia.org/wiki/Opera_(Internet_suite)#Opera_for_devices Just a thought. Opera is, of course, no open-source software. minime/tim ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Maximum SDHC capacity supported?
Subject: Re: Maximum SDHC capacity supported? Date: Fri 11 May 07 12:28:55PM +0200 Quoting Stefan Schmidt ([EMAIL PROTECTED]): > MicroSD is up to 4GB right now. As SHDC starts from 4GB there should > be no difference. > > The real problem is to buy such a card. Until now we were not able to > find a source for them. A bug for testing is already open: > > http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=93 > > If anybody knows a source for this cards let us know. We are eager to > buy and test. :) A quick search on preisroboter.de with keywords 'microsd' and '4gb' returns a number of merchants in germany, ready to take your money for such a card, apparently. SanDisk is the producer, and the cheapest one is sold at 74.89 euros including adapter for plain SD format and USB reader. Carlo -- * Se la Strada e la sua Virtu' non fossero state messe da parte, * K * Carlo E. Prelz - [EMAIL PROTECTED] che bisogno ci sarebbe * di parlare tanto di amore e di rettitudine? (Chuang-Tzu) ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Projection keyboards resource
Hello Found this interesting products description: http://www.alpern.org/weblog/stories/2003/01/09/projectionKeyboards.html The article is quite old, but who knows if some of these companies would'nt wish to integrate their technology with a mobile computing product ? The laser projected keyboards are quite interesting, i intend to use one with my (hypothetical-for-now) neo. But if it was integrated. you can imagine the consequences. Make sure to check out these ones: http://www.senseboard.com/ kitty http://www.kittytech.com/about-kitty.html ; i guess they belong mainly to sci-fi... When will we have the openmoko head mounted glasses and openmoko gloves ? ;) Cheers Florent ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: firefox for mobiles
It behaves far better on my laptop as well, I strongly suspect it has something to do with the 64bit nature of my desktop vs 32 for all other places I use it. My 64bit firefox is currently taking 1.8G of ram after having been started ~16 hours ago. Several groups of people, myself included, have submitted valgrind outputs that show massive memory hemorrhaging but the reports pretty much get ignored. :( More debug tools would go a long way towards letting the community find and fix these issues and make FF something desirable on the neo. I love the idea of the neo, but it's just too small in cpu/ram for some other (really neat) ideas. I'm impatient :D -david Ian Stirling wrote: > David Ford wrote: >> If it's anything like mozilla/firefox now, we're gonna need a hefty >> battery, hugely more cpu, and about 1G of ram onboard. > > Oddly. > It seems to behave OK on my laptop - 1.5 - which I was using for some > time with 128M RAM. > Admittedly, it did need restarted every day or three. > > The big problem is the lack of debug tools. > > I write a new extension. > I then want to profile it, to find out how much CPU, and how much CPU > it makes the core use. > I can't. > Worse, the same problem applies to most of the XUL/XBL/JS core. > ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Projection keyboards resource
On Friday 11 May 2007 13:53, Florent THIERY wrote: > http://www.alpern.org/weblog/stories/2003/01/09/projectionKeyboards.html > The article is quite old, but who knows if some of these companies > would'nt wish to integrate their technology with a mobile computing > product ? The laser projected keyboards are quite interesting, i Have you actually tried out some of these keyboards ? They get five stars for coolness, but they are still more of a showcase than a usable product. I had two or three models on testing but in the end I always reverted to on-screen pecking, frustrated by the typing experience on these keyboards. They are great for a 'press enter' sort of typing, but for text, especially if you are a touch typist or use more than one or two fingers to type, it's not fun at all. I'd take a stowaway bluetooth foldable keyboard over these anytime (and those aren't perfect either :). ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Some light ahead...
Sean Moss-Pultz wrote: Finally, we've already begun moving production into one of our factories in mainland China. There are two runs scheduled now: May 10th and May 20th. We're going to take those runs a bit slow just to make sure the quality is high. And then starting in June, things can run full speed. So? How did it go? Did they successfully roll off the assembly line? What percentage of the batch worked properly? Are we still on schedule, or has something popped up that is going to force things to slip again? Most importantly, when and where do I send my check? Dunc ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: firefox for mobiles
As announced this is a long term project, so there will be no firefox mobile in 2007 and maybe not in 2008. Firefox doesnt only use a massive amount of RAM, it also needs a powerful CPU. Imho a browser based on KHTML/WebKit, especially S60WebKit would be the best choise. Whoever has used one of the new S60 3rd Edition will agree, because that browser simply rocks (and is damn fast!). S60WebKit is partly OpenSource, only the UI isn't. http://opensource.nokia.com/projects/S60browser/ ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: firefox for mobiles
here is a test of minimo 0.2: http://ekstreme.com/thingsofsorts/fun-web/first-look-at-minimo ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
GNUstep/SimpleWebKit for mobiles - was: Firefox/opera for mobiles
An interesting project has started within GNUstep: SimpleWebKit. It is a simplified rework of the full WebKit API completely written in Objective-C (which requires Objective-C++ to compile). Footprint is quite small: the Linux ARM library currently has unstripped 1.4 MByte. Here is the link: http://wiki.gnustep.org/index.php/SimpleWebKit There is no known reason why it should not run on an Neo1973 as soon as it runs at all on GNUstep (there are some base classes missing). Am 11.05.2007 um 13:09 schrieb [EMAIL PROTECTED]: Right now I'm using Opera Mini on my Nokia6230, Opera Mini is J2ME based. It's not browser by conventional means as it uses some Opera-server for website customization and compression. As a Java Midlet it does not take up to much memory by any means - hence it's not as comfortable/convenient as any real browser ;-) Where Opera Mini comes for free, a more smartphone adapted version 'Opera Mobile' is commonly sold to smartphone manufactures. Opera Mini: http://mini.opera.com Java-Applet-Simulator: http://www.operamini.com/demo/ Opera for devices: http://en.wikipedia.org/wiki/Opera_(Internet_suite)#Opera_for_devices Just a thought. Opera is, of course, no open-source software. minime/tim ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Maximum SDHC capacity supported?
On 11/05/2007 7:41 PM, Florent THIERY wrote: > As there are some 8GB SDHC cards out there, are there limitations on > the neo? (as soon as it's SDHC, shoudl'nt be it ok?) Last I heard, from a Nokia employee working on the 770 & N800 SDHC is patented so they weren't able to add support for it in the N800. The only odd bit is that the patent is owned by Nokia themselves... signature.asc Description: OpenPGP digital signature ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GNUstep/SimpleWebKit for mobiles - was: Firefox/opera for mobiles
Am 11.05.2007 um 17:50 schrieb Dr. H. Nikolaus Schaller: An interesting project has started within GNUstep: SimpleWebKit. It is a simplified rework of the full WebKit API completely written in Objective-C (which requires Objective-C++ to compile). Footprint is quite small: the Linux ARM library currently has unstripped 1.4 MByte. Here is the link: http://wiki.gnustep.org/index.php/SimpleWebKit There is no known reason why it should not run on an Neo1973 as soon as it runs at all on GNUstep (there are some base classes missing). Sorry, the () is misplaced... Should read (that is one reason why I would prefer a forum system over mailing lists - you can simply 'edit' mistakes). It is a simplified rework of the full WebKit (which requires Objective-C++ to compile) API completely written in plain Objective-C. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Maximum SDHC capacity supported?
Julien Goodwin wrote: On 11/05/2007 7:41 PM, Florent THIERY wrote: As there are some 8GB SDHC cards out there, are there limitations on the neo? (as soon as it's SDHC, shoudl'nt be it ok?) Last I heard, from a Nokia employee working on the 770 & N800 SDHC is patented so they weren't able to add support for it in the N800. The only odd bit is that the patent is owned by Nokia themselves... well if they wanted to add support to said devices, they would have to licence the use of the patent to the community. this would in turn make them unable to licence it to other parties as they could in theory turn the community code into a free-standing library and use that... atleast thats my guess... ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: firefox for mobiles
While FF does have a fairly large footprint, I've never had these kinds of memory consumption problems. I generally leave my FF sessions open for days or weeks at home, and I simultaneously load 3D games, OOo, graphics apps, and other stuff without ever having trouble with memory (granted I do have 2GB). However, even the large memory footprint that I do see has an explanation, and can be tuned by tweaking about:config. By default, FF caches every page loaded on every tab for that sessions. If you consider a geek's multi-day surfing session, that is a lot of data to cache, and the cache data also can't be compressed. Since the primary target of FF is the "average" user -- which has several short surfing sessions and usually closes the browser between sessions -- the default settings make sense. If this is not your surfing style, then change your settings. That said, the full blown browser would be an awfully hefty app to put on a phone, and the minimo browser is currently targeting windows portables. Why not go with something with a tiny footprint, time-tested and proven lynx anyone? ~Bradley David Ford wrote: > It behaves far better on my laptop as well, I strongly suspect it has > something to do with the 64bit nature of my desktop vs 32 for all other > places I use it. My 64bit firefox is currently taking 1.8G of ram after > having been started ~16 hours ago. > > Several groups of people, myself included, have submitted valgrind > outputs that show massive memory hemorrhaging but the reports pretty > much get ignored. :( > > More debug tools would go a long way towards letting the community find > and fix these issues and make FF something desirable on the neo. > > I love the idea of the neo, but it's just too small in cpu/ram for some > other (really neat) ideas. I'm impatient :D > > -david > > Ian Stirling wrote: >> David Ford wrote: >>> If it's anything like mozilla/firefox now, we're gonna need a hefty >>> battery, hugely more cpu, and about 1G of ram onboard. >> Oddly. >> It seems to behave OK on my laptop - 1.5 - which I was using for some >> time with 128M RAM. >> Admittedly, it did need restarted every day or three. >> >> The big problem is the lack of debug tools. >> >> I write a new extension. >> I then want to profile it, to find out how much CPU, and how much CPU >> it makes the core use. >> I can't. >> Worse, the same problem applies to most of the XUL/XBL/JS core. >> > > ___ > OpenMoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > > ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: firefox for mobiles
Bradley Hook wrote: That said, the full blown browser would be an awfully hefty app to put on a phone, and the minimo browser is currently targeting windows portables. Why not go with something with a tiny footprint, time-tested and proven lynx anyone? i would prefer w3m or some other with image capability... but then i have not used lynx in ages... ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: firefox for mobiles
For the same reason I use open office instead of vi. Lynx is far from capable. Even with tuning, FF is a dastard piggy. I've tested things with FF. Start it with no history, no recovered session. Load up digg.com and do nothing. Just let it sit there. It will sit there and slowly grow and grow and grow. The caching isn't the problem, that's tunable. The problem is the memory leaks -- all the valgrind reports turned into moz teams (and ignored). Unless the current mozilla paradigm is changed, putting a moz product on a cellphone is not just asking but demanding people reboot their phones very often. I put minimo on my cellphone and I know once I use minimo, I can use my phone for about 12 hours or less before it gets so sluggish that I have to pull the battery out to reboot it because it won't respond to the power button any more. If I manage to get to the task list and kill minimo, it gets snappy again instantly. Mozilla are a great group of people and ideas and I've been very impressed with all the things that have been accomplished. Unfortunately pretty much everyone racing to eclipse them with browsers that are far faster, more W3C compliant, and just overall better at things. Mozilla seem intent on stagnating. Serious bugs (design flaws) that have been around for years are dismissed as "there isn't a right way to do it." Like fixed position background images and page scrolling. Alpha blending - transparent images with a background. Turns powerhouse desktop browsing into a horridly choppy stalling experience. I just can't envision Mozilla building a useful product for smart phones whether it's the Neo or any other phone. The neo is far from being a powerhouse device and sadly the M$ browser engine is far more capable and blindingly faster than minimo is. Bradley Hook wrote: > While FF does have a fairly large footprint, I've never had these kinds > of memory consumption problems. I generally leave my FF sessions open > for days or weeks at home, and I simultaneously load 3D games, OOo, > graphics apps, and other stuff without ever having trouble with memory > (granted I do have 2GB). > > However, even the large memory footprint that I do see has an > explanation, and can be tuned by tweaking about:config. By default, FF > caches every page loaded on every tab for that sessions. If you consider > a geek's multi-day surfing session, that is a lot of data to cache, and > the cache data also can't be compressed. Since the primary target of FF > is the "average" user -- which has several short surfing sessions and > usually closes the browser between sessions -- the default settings make > sense. If this is not your surfing style, then change your settings. > > That said, the full blown browser would be an awfully hefty app to put > on a phone, and the minimo browser is currently targeting windows > portables. Why not go with something with a tiny footprint, time-tested > and proven lynx anyone? > > ~Bradley ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Home-Brew IR port. Was - Please Ignore RS232 message. The subject should read IrDA port... Sorry
stupid gmail... sorry joe On 5/11/07, Jeff Andros <[EMAIL PROTECTED]> wrote: On 5/11/07, Joe Pfeiffer <[EMAIL PROTECTED]> wrote: > > Jeff Andros writes: > > >Chicken and egg hoss, there's also no bluetooth remotes out yet to make > it > >worthwhile to have a bluetooth remote... I like the suggestion of a > > TV sets come with remotes so routinely that the usual chicken/egg > problem doesn't seem to arise. Hmmm... which may point a different > direction: as long as bluetooth is more expensive than IR... > > my thought was if you're going to provide a bluetooth remote... it should probably be a universal one since you're jamming enough smarts to work a bluetooth stack in... it'd be killer to have a gateway system that makes everything work together, whether I'm sitting at my laptop, or just walking around with my phone in my pocket. it'd also be cool to not have to walk back out into the house to turn the other TV off when I decide to go to bed -- Jeff O|||O -- Jeff O|||O ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Home-Brew IR port. Was - Please Ignore RS232 message. The subject should read IrDA port... Sorry
Jeff Andros writes: >stupid gmail... sorry joe No problem >> > my thought was if you're going to provide a bluetooth remote... it >> should probably be a universal one since you're jamming enough smarts to >> work a bluetooth stack in... it'd be killer to have a gateway system that >> makes everything work together, whether I'm sitting at my laptop, or just >> walking around with my phone in my pocket. That would be very cool -- but you'd sort of expect TVs (and DVD players etc) to come with universal remotes, and they seem to come with anything from that down to a special-purpose remote that can only be used with the unit it came with... ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Sun JavaFx
On 5/10/07, Jim Thompson <[EMAIL PROTECTED]> wrote: Terrence Barr - Evangelist, Java Mobile & Embedded wrote: > Shawn, > > I have been very involved in this area at Sun now for a couple of > years. Let me add come comments: > > Hardware accelerated Java is actually fairly common already, at > least in the Java ME space using ARM's Jazelle technology. It does > have some benefits in very constrained platforms but in general > advanced VMs with dynamic adaptive optimizations, compilation, > and improved garbage collection perform better than H/W acceleration > and at reasonable incremental cost (memory footprint, in particular). > > I think what we are seeing here is a general trend in the IT industry > as general-purpose processors become more and more powerful they > displace dedicated hardware solutions because software solutions are > more flexible and lower cost. A notable exception, of course, is > graphics acelleration but Java implementations typically use those > when available. > > Specifically to Sun's Java chips (picoJava/microJava): I worked on them > and the performance was quite good. But it is very hard, if not > impossible, to keep up with performance improvements of general > purpose processors together with the increasing amount of memory > available. That technology evolution relegates Java hardware > acceleration to niche status. Many companies have invested in Java > H/W acceleration and fell into that trap. It turns out to be difficult to make Java go really fast on specialized hardware. Java wasn't designed to be fast, it was designed to be 'safe' Why is it so hard? What are the tough problems that are always going to be slow? What's wrong with taking some shortcuts, like the way KVM depends on pre-verified bytecodes so that it doesn't have to do the verification at load time? for large groups of programmers to use. You can get single order of magnitude speed-ups for some bytecode streams, but you won't see two. I (too) looked at doing a Java chip (very early, back in 1996 or so). Moore's law continues to march on, only now instead of (super)-linear speed-up on a single core, we're getting multiple cores. Java will be OK with 'multi-core', but won't survive the transition to 'manycore' (> 100 cores), nor will Python, PHP or Perl. This may not matter on a phone platform, but the desktop and server will distance themselves from co-operating sequential processes before too much longer. I think you are saying that the thread model of concurrency has limits, right? Or just that programmers will balk at having to manage hundreds of threads? Well what do you think is the future then, to get more parallelism? The only question is if the rest of the industry 'woke up' enough to see the light of cracking the phone wide-open. If not, they are doomed. Yeah that's a big one. I think Apple's view is that their applications are always best-of-breed anyway, and they can satisfy 90% of the users' needs themselves, so why be open to having third-party security holes, usability problems, bugs and so on, which will sully the reputation of the phone. But I also think a lot of the success of the early Palms was the wide variety of extra software you could install on them. I doubt that Apple will really keep the iPhone closed forever, but we'll see. Nowadays it's not like it was in the Palm era though... there are so many choices for development platform. Java, Brew, Windows Mobile, Palm, Symbian, Linux/QT, Linux/X, etc. Java has not been the unifying force that it should have been. I'm not very optimistic that is suddenly going to happen; the window has probably been missed. But I guess it's worth a try. If nothing else at least OpenMoko might be able to run Java games or something. I think one unsolved problem, which has probably hampered Java a lot, is the lack of a process model. If a Java VM was pre-loaded, and all of the Java applications could run in one VM, the overhead for each one would be much less, right? I know, I've heard the excuse... well, the OS is caching files anyway, each class's instructions are only being loaded once, and a separate VM increases security. But if a phone's top priority at bootup was to just to get all of the necessary classes into memory as fast as possible, and get the VM running, get the UI up and be ready to do the basic phone stuff (calls, phonebook etc.) maybe it could be fast. But Java has always been an adjuct. On the desktop, first you have all the overhead of the OS and its own UI, and then there is Java. Anytime I run a desktop Java app my reaction is ugh, you can always recognize a Java app by the startup time, the amount of memory it's taking up, and the paint idiosyncracies and the way the UI looks. And the installer typically put its own VM in place along with the app. So you will be running a different VM for every app. This is not a platform! And the phones I have worked with are just limited to one Java app at a
Re: Sun JavaFx
Shawn, I'm more than happy to engage and debate these points, but its likely off-topic (or at least not "in scope") for the list (which is about openmoko and/or the community that surrounds openmoko). Topics such as: "why is Java slow" (and how to construct hw to make it go fast concurrency models (threads or not) programming of same, and Java's lack of a process model aren't related (much) to openmoko, so I suggest we take these off-line, unless 'the list' decides they would rather watch/join the discussion here. (And yes, I agree that I contributed to the discussion going off-track.) The topic of Apple being open or closed, especially as it relates to the iPhone, seems at least peripheral to the discussion here. I think it likely to be mere months before some rudimentary linux kernel is running on the iPhone, and likley less than a year from then until some dedicated group of hackers make the OpenMoko environment run on the iPhone in much the same way that the Mac and the "AppleTV", and even the iPod now run specialized linux kernels to 'enable' a degree of openness that Apple expressly did not plan. If OpenMoko is found to be a better environment than (or for) the iPhone (as well as other phones)... "success!". If Sun's "JavaFX Mobile", well... "success"! Jim Shawn Rutledge wrote: On 5/10/07, Jim Thompson <[EMAIL PROTECTED]> wrote: Terrence Barr - Evangelist, Java Mobile & Embedded wrote: > Shawn, > > I have been very involved in this area at Sun now for a couple of > years. Let me add come comments: > > Hardware accelerated Java is actually fairly common already, at > least in the Java ME space using ARM's Jazelle technology. It does > have some benefits in very constrained platforms but in general > advanced VMs with dynamic adaptive optimizations, compilation, > and improved garbage collection perform better than H/W acceleration > and at reasonable incremental cost (memory footprint, in particular). > > I think what we are seeing here is a general trend in the IT industry > as general-purpose processors become more and more powerful they > displace dedicated hardware solutions because software solutions are > more flexible and lower cost. A notable exception, of course, is > graphics acelleration but Java implementations typically use those > when available. > > Specifically to Sun's Java chips (picoJava/microJava): I worked on them > and the performance was quite good. But it is very hard, if not > impossible, to keep up with performance improvements of general > purpose processors together with the increasing amount of memory > available. That technology evolution relegates Java hardware > acceleration to niche status. Many companies have invested in Java > H/W acceleration and fell into that trap. It turns out to be difficult to make Java go really fast on specialized hardware. Java wasn't designed to be fast, it was designed to be 'safe' Why is it so hard? What are the tough problems that are always going to be slow? What's wrong with taking some shortcuts, like the way KVM depends on pre-verified bytecodes so that it doesn't have to do the verification at load time? for large groups of programmers to use. You can get single order of magnitude speed-ups for some bytecode streams, but you won't see two. I (too) looked at doing a Java chip (very early, back in 1996 or so). Moore's law continues to march on, only now instead of (super)-linear speed-up on a single core, we're getting multiple cores. Java will be OK with 'multi-core', but won't survive the transition to 'manycore' (> 100 cores), nor will Python, PHP or Perl. This may not matter on a phone platform, but the desktop and server will distance themselves from co-operating sequential processes before too much longer. I think you are saying that the thread model of concurrency has limits, right? Or just that programmers will balk at having to manage hundreds of threads? Well what do you think is the future then, to get more parallelism? The only question is if the rest of the industry 'woke up' enough to see the light of cracking the phone wide-open. If not, they are doomed. Yeah that's a big one. I think Apple's view is that their applications are always best-of-breed anyway, and they can satisfy 90% of the users' needs themselves, so why be open to having third-party security holes, usability problems, bugs and so on, which will sully the reputation of the phone. But I also think a lot of the success of the early Palms was the wide variety of extra software you could install on them. I doubt that Apple will really keep the iPhone closed forever, but we'll see. Nowadays it's not like it was in the Palm era though... there are so many choices for development platform. Java, Brew, Windows Mobile, Palm, Symbian, Linux/QT, Linux/X, etc. Java has not been the unifying force that it should have been. I'm not very optimistic that is suddenly going to happen; the window has probably bee
Re: Sun JavaFx
Jim Thompson writes: >aren't related (much) to openmoko, so I suggest we take these off-line, >unless 'the list' decides they would rather watch/join the discussion >here. (And yes, I agree that I contributed to the discussion going >off-track.) I for one have been interested (decades ago I was involved in special-purpose SIMD computers for computer vision, so I'm very familiar with watching Moore's Law overtake and bury specialized hardware!). ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Setting up the SDK
I got the emulator for the NEO 1973 up and running, it took a simple code
tweak for it to build with gcc 4.1.1. Now I am looking for more info about
getting the SDK installed so I can play around with it a bit. Can anyone
point me to some more info about it?
CaseyB
P.S.
Here's the diff of the change I made.
Index: hw/neo1973.c
===
--- hw/neo1973.c(revision 1942)
+++ hw/neo1973.c(working copy)
@@ -121,13 +121,11 @@
static void neo_gps_switch(int line, int level, void *opaque)
{
-neo_printf("GPS %sV supply is now %s.\n",
-#ifdef GTA01Bv3
-line == GTA01_GPIO_GPS_EN_3V3 ? "3.3" : "3.0",
+#if defined(GTA00Bv3)
+neo_printf("GPS %sV supply is now %s.\n",line == GTA01_GPIO_GPS_EN_3V3
? "3.3" : "3.0",level ? "on" : "off");
#else
-line == GTA01_GPIO_GPS_EN_2V8 ? "2.8" : "3.0",
+neo_printf("GPS %sV supply is now %s.\n",line == GTA01_GPIO_GPS_EN_2V8
? "2.8" : "3.0",level ? "on" : "off");
#endif
-level ? "on" : "off");
}
static void neo_gps_rst_switch(int line, int level, void *opaque)
___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
