Re: One second Openmoko boot?
On 9/5/09, Rask Ingemann Lambertsen ccc94...@vip.cybercity.dk wrote: On Thu, Aug 20, 2009 at 08:21:07AM +0100, Rui Miguel Silva Seabra wrote: Just a few more cents from me... Have you guys ever seen one of those other smartphones booting? They take ages too. The main difference is that we have to boot more often :) Do we? I can't comment on your SHR problems because I don't use it, but Debian doesn't exactly need rebooting. Just put in a menu entry to restart fso-frameworkd that you can quickly get to when the screen blanker part stops reacting to screen touches. How old frameworkd do you have in Debian? All issues with IdleNotifier should be already fixed! -- Sebastian Krzyszkowiak dos ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: One second Openmoko boot?
How old frameworkd do you have in Debian? All issues with IdleNotifier should be already fixed! the official one is still 5.1, and there are packages by heiko stübner for 5.5 from mid-august (i guess, the packages are from august 20th). isn't there a way to follow the shr releases for debian? it would speed up the release cycles a lot. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: One second Openmoko boot?
On 9/6/09, arne anka openm...@ginguppin.de wrote: How old frameworkd do you have in Debian? All issues with IdleNotifier should be already fixed! the official one is still 5.1, and there are packages by heiko stübner for 5.5 from mid-august (i guess, the packages are from august 20th). isn't there a way to follow the shr releases for debian? it would speed up the release cycles a lot. SHR uses always newest frameworkd from git, as frameworkd from git is rather kept stable all the time ;) -- Sebastian Krzyszkowiak dos ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: One second Openmoko boot?
How old frameworkd do you have in Debian? All issues with IdleNotifier should be already fixed! the official one is still 5.1, and there are packages by heiko stübner for 5.5 from mid-august (i guess, the packages are from august 20th). isn't there a way to follow the shr releases for debian? it would speed up the release cycles a lot. I hope that we will improve the situation and will constantly provide more or less up-to-date fso in debian. Just things take some time because of the nature of debian. Nikita signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: One second Openmoko boot?
SHR uses always newest frameworkd from git, as frameworkd from git is rather kept stable all the time ;) ok. brings me back to my old question: how does one create deban packages from git? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: One second Openmoko boot?
Just things take some time because of the nature of debian. sure. but the nature of debian plus low man power in pkg-fso adds up to a rather large delay. i am still confused by the complexity of creating deb packages and i don't use git so far (and probably will not until a working eclipse plugin is avaliable with functionality comparable to the cvs and svn ones), thus i can't even create packages of fso for my own use. hopefully things will clear up a bit in the fall, when i got more time. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: One second Openmoko boot?
SHR uses always newest frameworkd from git, as frameworkd from git is rather kept stable all the time ;) ok. brings me back to my old question: how does one create deban packages from git? Debian packaging for fso components is done from git. Pkg-fso repositories in git.debian.org are clones of repositories on git.freesmartprone.org, with debian packaging files added on separate branches. Packages are built using git-builtpackage tool. Currently native build is used; either on armel machine (either freerunner itself, or debian armel autobuilder), or in qemu-pbuilder on any debian system. Cross build could be probably handled by emdebian tools - I did not try. Nikita signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: One second Openmoko boot?
On Sunday 06 September 2009 13:20:01 Nikita V. Youshchenko wrote: How old frameworkd do you have in Debian? All issues with IdleNotifier should be already fixed! the official one is still 5.1, and there are packages by heiko stübner for 5.5 from mid-august (i guess, the packages are from august 20th). isn't there a way to follow the shr releases for debian? it would speed up the release cycles a lot. I hope that we will improve the situation and will constantly provide more or less up-to-date fso in debian. Great. On our side, I will make sure we regularly spin tarball releases. :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: One second Openmoko boot?
Debian packaging for fso components is done from git. Pkg-fso repositories in git.debian.org are clones of repositories on git.freesmartprone.org, with debian packaging files added on separate branches. could you give some step by step commands? how do i check out the most recent version with everything? Packages are built using git-builtpackage tool. hm. how do i use that? Cross build could be probably handled by emdebian tools - I did not try. i create frinst navit pacakges that way, by simply doing fakeroot dpkg-buildpackage -b -aarmel so, all i need is a directory with the sources and debian/ subdir. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: One second Openmoko boot?
Debian packaging for fso components is done from git. Pkg-fso repositories in git.debian.org are clones of repositories on git.freesmartprone.org, with debian packaging files added on separate branches. could you give some step by step commands? how do i check out the most recent version with everything? If we had the most recent version with everything in ready-to-build form, that would have been already uploaded to debian :) Sorry, no free time to write step-to-step guidelines. Packaging repos are at git.debian.org (search for pkg-fso there). See git manual [1] on how to clone those, add freesmartphone.org remote, fetch from there and merge new code and debian packaging together. See git-buildpackage manual [2] on how to use git-buildpackage. [1] http://git-scm.com/documentation [2] http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.html Nikita signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: One second Openmoko boot?
On Thu, Aug 20, 2009 at 08:21:07AM +0100, Rui Miguel Silva Seabra wrote: Just a few more cents from me... Have you guys ever seen one of those other smartphones booting? They take ages too. The main difference is that we have to boot more often :) Do we? I can't comment on your SHR problems because I don't use it, but Debian doesn't exactly need rebooting. Just put in a menu entry to restart fso-frameworkd that you can quickly get to when the screen blanker part stops reacting to screen touches. -- Rask Ingemann Lambertsen Danish law requires addresses in e-mail to be logged and stored for a year ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: One second Openmoko boot?
On Friday 21 August 2009 06:21:52 Wolfgang Spraul wrote: Not really. Reloading (in the worst case) 128MB from an SD is not exactly fast either. The only sane way to substantially improve booting time is to stop booting like a desktop PC, that is move away from starting all services just because you can. Start them on demand and bring only the bare necessities up on boot (filesystems, dbus, X). Not sure. What I have seen working usually required much more aggressize optimization, all the way into hardware. Of course. I have been referring to the FreeRunner though, i.e. what can we do on already existing hardware with pure software. No doubt that hardware, especially considering this right from the start, makes a much more substantial difference. :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: One second Openmoko boot?
Michael 'Mickey' Lauer wrote: On Friday 21 August 2009 06:21:52 Wolfgang Spraul wrote: Not really. Reloading (in the worst case) 128MB from an SD is not exactly fast either. The only sane way to substantially improve booting time is to stop booting like a desktop PC, that is move away from starting all services just because you can. Start them on demand and bring only the bare necessities up on boot (filesystems, dbus, X). Not sure. What I have seen working usually required much more aggressize optimization, all the way into hardware. Of course. I have been referring to the FreeRunner though, i.e. what can we do on already existing hardware with pure software. No doubt that hardware, especially considering this right from the start, makes a much more substantial difference. The FR wakes up fast enough from sleep. (suspend-to-RAM) Now, implement suspend-to-disk (SD-card), and you can start reasonably quick after changing the battery. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: One second Openmoko boot?
On Friday 21 August 2009 16:36:07 Helge Hafting wrote: Now, implement suspend-to-disk (SD-card), and you can start reasonably quick after changing the battery. It should take around 40 seconds to read the memory back from SD, so if you can live with that, implementing suspend-to-disk might be interesting. Still I prefer working on the actual boot process, since getting away from booting like a PC will also have positive effects on memory consumption and battery lifetime. :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: One second Openmoko boot?
Michael 'Mickey' Lauer wrote: The only sane way to substantially improve booting time is to stop booting like a desktop PC, that is move away from starting all services just because you can. Start them on demand and bring only the bare necessities up on boot (filesystems, dbus, X). Yes, doing less work is the most promising approach here. You can also try to move moredrivers into modules, replace udev, and move to uSD, avoiding JFFS2. (JFFS2 and udev conspire to create a huge startup cost, with udev's expensive initialization and JFFS2 doing its garabge collection at the same time.) - Werner ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: One second Openmoko boot?
Michael 'Mickey' Lauer wrote: On Friday 21 August 2009 16:36:07 Helge Hafting wrote: Now, implement suspend-to-disk (SD-card), and you can start reasonably quick after changing the battery. It should take around 40 seconds to read the memory back from SD, so if you can live with that, implementing suspend-to-disk might be interesting. I like the hybrid suspend method that is used by apple (and possibly others) They do suspend to RAM for fast resume. But also do suspend to disk. And if the battery runs out (or is yanked out for replacement) the system comes up again from disk. It would be neat to have. If it is easy. Remember, there is almost absolutely no use case for total shutoff and suspend to 'Disk' since you want your GSM to stay on line on suspend. And for that everything but past resume from RAM is useless. Resume speed is in my eyes just not a issue. Boot speed is something else. The only reason to boot a phone is if it crashed, ran out of battery or kernel update. Avoiding reboots seems to be the answer for me. Not that it would be cool it it could boot faster. But any modern smartphone has horrendous boot times this day. How long could a phone on a almost empty battery survive after it has shut off all radios and gone into standby? We could maybe have some 'survival' mode to make it to the next charger without shutting off. If that is worth it at all. Still I prefer working on the actual boot process, since getting away from booting like a PC will also have positive effects on memory consumption and battery lifetime. +1 Booting after init still takes ages. I don't know, but it seems to be a IO throughput problem rather then CPU speed. Maybe more compression can help? Just a hunch, I'm basically clueless. And of course delaying stuff. What I would wish for is quicker GSM login. I think have the latest firmware, but SHR still takes ages after the phone is fully booted until it is on line. -- MFG Tilman Baumann ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: One second Openmoko boot?
2009/8/21 Tilman Baumann til...@baumann.name Remember, there is almost absolutely no use case for total shutoff and suspend to 'Disk' since you want your GSM to stay on line on suspend. And for that everything but past resume from RAM is useless. There are many use cases if you're on battery for an extended period (for example when traveling) and don't need the GSM to be online all the time. There have been a few occasions where suspend to disk would have helped me, assuming reasonable wakeup time. But I understand I'm in the minority. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: One second Openmoko boot?
On Fri, Aug 21, 2009 at 6:52 PM, Michal Brzozowskiruso...@poczta.fm wrote: 2009/8/21 Tilman Baumann til...@baumann.name Remember, there is almost absolutely no use case for total shutoff and suspend to 'Disk' since you want your GSM to stay on line on suspend. And for that everything but past resume from RAM is useless. There are many use cases if you're on battery for an extended period (for example when traveling) and don't need the GSM to be online all the time. There have been a few occasions where suspend to disk would have helped me, assuming reasonable wakeup time. But I understand I'm in the minority. I would also like suspend to disk and agree that there are a number of use cases when it is very practical. For example I am often out of the country for a weekend. Often it is not practical to recharge the phone during that time and it would be a lot easier if I could just suspend to disk and quickly check for missed msgs every couple of hours or so. Maybe I am biased because I also always suspend my laptop to disk, so know from experience how nice it is to be able to quickly boot up :) Cheers, Edder ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: One second Openmoko boot?
On 21 Aug 2009, at 18:10, Edder wrote: On Fri, Aug 21, 2009 at 6:52 PM, Michal Brzozowskiruso...@poczta.fm wrote: 2009/8/21 Tilman Baumann til...@baumann.name Remember, there is almost absolutely no use case for total shutoff and suspend to 'Disk' since you want your GSM to stay on line on suspend. And for that everything but past resume from RAM is useless. There are many use cases if you're on battery for an extended period (for example when traveling) and don't need the GSM to be online all the time. There have been a few occasions where suspend to disk would have helped me, assuming reasonable wakeup time. But I understand I'm in the minority. I would also like suspend to disk and agree that there are a number of use cases when it is very practical. For example I am often out of the country for a weekend. Often it is not practical to recharge the phone during that time and it would be a lot easier if I could just suspend to disk and quickly check for missed msgs every couple of hours or so. Well yea, but it's a phone after all. :) I would be really interested how long the phone would survive on the deepest not off sleep possible (No radio, all chips possible shut off). That could beat system to disk I would expect. Maybe I am biased because I also always suspend my laptop to disk, so know from experience how nice it is to be able to quickly boot up :) Your laptop would probably survive for three month on suspend to RAM. ;-) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: One second Openmoko boot?
On Friday 21 August 2009 18:13:14 Tilman Baumann wrote: Booting after init still takes ages. I don't know, but it seems to be a IO throughput problem rather then CPU speed. We're just doing too much at this stage. What I would wish for is quicker GSM login. I think have the latest firmware, but SHR still takes ages after the phone is fully booted until it is on line. Agreed. Part of it is the really slow Calypso, but all the python stuff contributes to it as well. This will improve gradually as we come up with FSO2 subsystems. :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: One second Openmoko boot?
On Wed, Aug 19, 2009 at 09:56:42PM -0500, c_c wrote: Hi, I would look for a decent middle path. A reasonable boot time, perhaps 30 secs to fully usable, and charging required in say 3 days of some measure of activity assumed to be normal (we could define something as a benchmark). And for a hell of a lot more smarts from a 'smart'phone. How about sync with desktop apps/on the net (yes PISI is getting there), notifications, reminders, alarms, PIM apps, stable accelerometer based rotation etc. I have to say that things have improved drastically over the last year - but then the FR should have been here long ago. Maybe openmoko could have done a lot better if the FR was where it is heading for right now (buzz-fix, bass-fix, #1024 fix, software stack improvements). I cant wait to get this phone running the (future) fully compiled FSO stack. Already the parts that are compiled are making a huge difference to the phone's performance. We're getting there. Now, if only we could write down a priority wise sequence of problems that need solving somewhere and tackle them one at a time with all the resources we have. Just a few more cents from me... Have you guys ever seen one of those other smartphones booting? They take ages too. The main difference is that we have to boot more often :) The current boot time of SHR is IMHO acceptable if I hadn't to reboot every so often. Rui ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: One second Openmoko boot?
Any chance suspend to disk, or 'hibernate' would work on openmoko? 2009/8/19 Glenn glenn.mh...@gmail.com Maybe this might be possible in some future of Openmoko Linux?: 07/15/09, NEWS: MontaVista claims an ultra-fast 1 second Embedded Linux Boot Time: http://www.embedded.com/products/softwaretools/218500563?_requestid=93912 One Second Linux Boot Demonstration (new version) - with list of used enhancements: http://www.youtube.com/watch?v=-l_DSZe8_F8 July 14, 2009, MontaVista Achieves Ultra-fast One Second Linux Boot Time in Embedded Industrial Applications: http://www.mvista.com/press_release_detail.php?fid=news/2009/Ultra-fast-boot.html /Glenn ___ 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: One second Openmoko boot?
On Thursday 20 August 2009 10:02:45 Michal Brzozowski wrote: Any chance suspend to disk, or 'hibernate' would work on openmoko? Not really. Reloading (in the worst case) 128MB from an SD is not exactly fast either. The only sane way to substantially improve booting time is to stop booting like a desktop PC, that is move away from starting all services just because you can. Start them on demand and bring only the bare necessities up on boot (filesystems, dbus, X). I plan to do some proof of concepts when my time allows... :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: One second Openmoko boot?
Mickey, Not really. Reloading (in the worst case) 128MB from an SD is not exactly fast either. The only sane way to substantially improve booting time is to stop booting like a desktop PC, that is move away from starting all services just because you can. Start them on demand and bring only the bare necessities up on boot (filesystems, dbus, X). Not sure. What I have seen working usually required much more aggressize optimization, all the way into hardware. Two examples: 1. Blackberry (old model, at least 2 years old) Cold boot only happens when I take out the battery. Otherwise the 'power off' button will just do some form of suspend (probably suspend to flash). It takes about 8 seconds to 'turn on' (probably from flash), and the most amazing thing, it only takes another 3-4 seconds until the first new email arrives in the Inbox. They probably optimized for this case ALL THE WAY THROUGH the apps, OS design, HW design, maybe even GSM chipset. Interestingly, after the first mail it takes maybe 5 seconds or so for the following mails to arrive, so they optimized the case of 'just get the first new mail into the Inbox asap' and postpone some other vital system initialization until after the first mail got delivered. 2. old Palms, late 90's They kept the whole memory in a low-power self-refresh mode. If you took out the batteries, you had about 1 minute or so to put new batteries in (during that time an internal backup battery would keep the RAM alive). If you didn't do that, all your data on the device was lost (but would be restored during the next HotSync from your desktop). Other than that, if you turned the device off you actually didn't turn it off at all. You only sent the whole system into this super low power mode where it still would keep the memory alive. It could stay like this on the battery for about 2-3 weeks. Wolfgang On Thu, Aug 20, 2009 at 05:17:25PM +0200, Michael 'Mickey' Lauer wrote: On Thursday 20 August 2009 10:02:45 Michal Brzozowski wrote: Any chance suspend to disk, or 'hibernate' would work on openmoko? Not really. Reloading (in the worst case) 128MB from an SD is not exactly fast either. The only sane way to substantially improve booting time is to stop booting like a desktop PC, that is move away from starting all services just because you can. Start them on demand and bring only the bare necessities up on boot (filesystems, dbus, X). I plan to do some proof of concepts when my time allows... :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: One second Openmoko boot?
Maybe this might be possible in some future of Openmoko Linux? Yes and no. Of course and not. :-) Depends on what your definition of cold boot is. There are trade-offs here, as always. As I understand it, the read-only text of the kernel was in ROM (could have been Flash), so did not have to be read in off a file system and loaded. On the other hand they were loading and initializing device drivers, and on a fixed system like the Openmoko you probably could cut down on that process quite a bit. Issues like memory bandwidth to the processor, processor speed, etc. etc. But the real question is, what was the customer need that drove the work? Probably a lot of engineering work went into that one second boot, but what would a one second boot (versus a two second or three second boot) really gain the FreeRunner unless you had a boot on incoming event, and a way to capture that event until the phone had booted and could handle it? IMHO what would be more useful is even more power management work to make the battery last longer in normal running mode, suspend and deep suspend, rather than shortening the (hopefully) once per year boot cycle. Warmest regards, md ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: One second Openmoko boot?
On Wed, Aug 19, 2009 at 04:01:29PM -0400, Jon 'maddog' Hall wrote: make the battery last longer in normal running mode, suspend and deep suspend, rather than shortening the (hopefully) once per year boot cycle. Once per year? :) Up until recently was once per day (minimum), but since 8-8's SHR-U I haven't returned to that sad average! Rui ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: One second Openmoko boot?
Once per year? :) Up until recently was once per day (minimum), but since 8-8's SHR-U I haven't returned to that sad average! /* gentle rant on Which is *exactly* my point. I have a friend of mine who's multi-user Linux system was recently up for thirty days before a power failure caused it to go down. I had a Digital Unix system on my desk up for an entire year without rebooting. We had cases of VAX/Ultrix systems up for over three years without a reboot. IMHO the only time you should have to cold reboot an operating system is when there is a change to a critical section of the kernel, or perhaps a hardware failure and with loadable kernel modules and loadable device drivers (to say nothing of user-mode device drivers), those sections and failures are relatively few. Sooo, while booting in one second is a neat stunt, and nice for automotive needs, or deep space probes that have a master controlling module that turns another module on and off; for a phone I would rather have it function like a real phone for four (or even three or even two or even one) days without rebooting or having to be recharged. On the other hand, there is the source codego to it. gentle rant off */ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: One second Openmoko boot?
2009/8/20 Jon 'maddog' Hall mad...@li.org: I have a friend of mine who's multi-user Linux system was recently up for thirty days before a power failure caused it to go down. I had a Digital Unix system on my desk up for an entire year without rebooting. We had cases of VAX/Ultrix systems up for over three years without a reboot. IMHO the only time you should have to cold reboot an operating system is when there is a change to a critical section of the kernel, or perhaps a hardware failure and with loadable kernel modules and loadable device drivers (to say nothing of user-mode device drivers), those sections and failures are relatively few. i think this whole idea is fatelly flawed i've never understood the fascination of linux users with keeping systems up for days and months on end. sure, it's great for a server hosting web sites, or in a corporate environment, but for a home system? it comes across as nothing more than who's the most '1337', which is really lame. add to that the power wasted and it's verging on the pointless as for phones, there are many reasons i turn mine off - not least because there's no way i want to be contactable at night, and when i'm doing other things where i don't want to be interrupted. it gets turned on and off at least once a day. my phone exists to serve me, not the other way around do you realise the effects of the 'always-connected' lifestyle? they're not good at all /return rant over anyway, the point i'm getting at is: a quick boot time, it doesn't have to be one second, is definitely an advantage ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: One second Openmoko boot?
i've never understood the fascination of linux users with keeping systems up for days and months on end. sure, it's great for a server hosting web sites, or in a corporate environment, but for a home system? it comes across as nothing more than who's the most '1337', which is really lame. add to that the power wasted and it's verging on the pointless I turn my systems off at home to save power, lifetime on fans and disks. That is not the point. The point is that *I* turn them off, versus some instability that causes the system to crash. The fact that a multi-user, network-connected, resource-limited system *can* stay up that long is (IMHO) desirable. as for phones, there are many reasons i turn mine off - not least because there's no way i want to be contactable at night, and when i'm doing other things where i don't want to be interrupted. it gets turned on and off at least once a day. my phone exists to serve me, not the other way around Ahhh, the difference between a phone and a portable computing device that can make telephone calls. I want my phone to be an alarm clock, a calendar, a music playerand I want it to have the *capability* of running twenty-four hours a day, seven days a week, efficiently, and without me having to futz too much with it, or to worry if I have to find its electric fix three times a day. Or to *have* to turn it off because I am not near an outlet for a long enough period of time. do you realise the effects of the 'always-connected' lifestyle? they're not good at all I do not typically give out my cell phone number. I consider my cell phone for my convenience and not others. Again, that is not the point. You are welcome to turn off your cell phone any time you want, or leave it on and make it silent, ready to receive messages and let it save them for you. Turn it off, and it is a boat anchor. Worse than a boat anchor, because at least a boat anchor is heavy enough to hold a boat in place. As to the power wasted, the always on, connected cell phone uses less power in a day than my laptop uses in an hour...and if it goes into deep suspend, a lot less than that. Power management in servers, desktops, laptops and netbooks is also necessary, and can help cellphones too, in the long run. anyway, the point i'm getting at is: a quick boot time, it doesn't have to be one second, is definitely an advantage Granted. But if there is a choice of where to put engineering talent? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: One second Openmoko boot?
Hi, I would look for a decent middle path. A reasonable boot time, perhaps 30 secs to fully usable, and charging required in say 3 days of some measure of activity assumed to be normal (we could define something as a benchmark). And for a hell of a lot more smarts from a 'smart'phone. How about sync with desktop apps/on the net (yes PISI is getting there), notifications, reminders, alarms, PIM apps, stable accelerometer based rotation etc. I have to say that things have improved drastically over the last year - but then the FR should have been here long ago. Maybe openmoko could have done a lot better if the FR was where it is heading for right now (buzz-fix, bass-fix, #1024 fix, software stack improvements). I cant wait to get this phone running the (future) fully compiled FSO stack. Already the parts that are compiled are making a huge difference to the phone's performance. We're getting there. Now, if only we could write down a priority wise sequence of problems that need solving somewhere and tackle them one at a time with all the resources we have. -- View this message in context: http://n2.nabble.com/One-second-Openmoko-boot--tp3474833p3476622.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Re: One second Openmoko boot?
Robin Paulson wrote: i've never understood the fascination of linux users with keeping systems up for days and months on end. sure, it's great for a server hosting web sites, or in a corporate environment, but for a home system? it comes across as nothing more than who's the most '1337', which is really lame. add to that the power wasted and it's verging on the pointless AFAIK, theres' only one problem with the fascination of never rebooting - and it's not power consumption. If you never reboot your servers under controlled circumstances, you have no guarantee that they will come up nicely in event of a forced reboot. /Peter ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
