Re: Visudo Help
On Thursday 16 August 2007 20:44:16 Paul Klapperich wrote: > On 8/16/07, James Sparenberg <[EMAIL PROTECTED]> wrote: > > On this one visudo is not on the box but the real solution is don't > > chmod the file. VI it as root, then instead of doing wq to quit (write > > quit) do wq! (w q then exclamation point or more commonly known as bang) > > this will override the read only aspect and commit your changes without > > running the risk of forgeting to chmod > > > > James > > which is what I was driving at, but that won't protect against errors > as visudo will also. Visudo is in /sbin on the device. It works fine. > > --Paul > ___ > maemo-users mailing list > maemo-users@maemo.org > https://lists.maemo.org/mailman/listinfo/maemo-users Paul, All I can say on the protection is... you greatly underestimate me *grin* as for visudo nope on my Nokia but that's ok. Seriously though you can make just as high quality mistakes with visudo as you can using vi and ! to override. Which is IMHO one more good reason to set your root password. Then if you crunch /etc/sudoers you can su to root and correct the error. James James ___ maemo-users mailing list maemo-users@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-users
Re: Battery Life
On Fri, 2007-08-17 at 10:46 +0300, Eero Tamminen wrote: > >> How do we know what the actual current consumption is? > > You use extra hardware for that, not software. :-) I always wondered if the N800 platform made this information available. I'm still wondering what the proprietary power management software really gets as raw info about battery state :). Laurent ___ maemo-users mailing list maemo-users@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-users
Promising GlideMobile
Here's something that shows the promise of being practical and useful -- the new version (2.0 Beta) of Glide on a PC/Mac/Linux desktop combined with 770/800 access through GlideMobile. Plus a GlideSync application for convenient uploading from the desktop. http://www.glidedigital.com/ https://www.glidemobile.com/ Glide is an online "unified file and information management system" with PIM, editing, storage, online applications, email, RSS, etc., capabilities. It's free with 2GB of space. http://www.transmediacorp.com/news/news_8-1-07.html The key to its usefulness is that when logged onto GlideMobile most everything can be accessed through (and with the limitations of) the standard browser on the 770/800. I've only been experimenting with contacts, bookmarks, documents, and a few graphics (N770 and Mac OS X 10.4.10). Email is convenient from the 770 but has some bugs on the Mac. Glide can be slow at times with a few quirks, but consider what gyrations it has to go through. There is a lot of potential simply in it becoming a common denominator for a wide variety of files and functions. --Don ___ maemo-users mailing list maemo-users@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-users
Re: maemo-users Digest, Vol 28, Issue 35
Thanks a ton! -- Dave > > "Click to install" doesn't work on the 770. You have to add the repository to > the Application Manager by hand. In the Application Manager, use the > Tools/Application catalogue... menu item and add a new catalogue. If you go > to http://www.cobb.uk.net/770 you will see the details you need to enter (you > want the "gregale" distribution). If you then "Refresh the list of packages" > you should see gpe-calendar in the list and available to install. > ___ maemo-users mailing list maemo-users@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-users
Reorganizing bugs.maemo.org
We are planning to reorganize the products and components structure in http://bugs.maemo.org in order to make it more user friendly and manageable. We also want to have a structure platform-centric, without being so defined by hardware as it is now. http://maemo.org/community/wiki/bugsmaemoorgreorg/ Feedback appreciated, in the wiki or here. -- Quim Gil - http://maemo.org ___ maemo-users mailing list maemo-users@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-users
Re: how to install GPE Calendar?
On Friday 17 August 2007 09:23, Marius Vollmer wrote: > But, downloads.maemo.org claims that GPE Calendar works with both IT > OS 2007 and IT OS 2006, so the .install file should have entries for > both. It only has one for IT OS 2007, tho, and that is the problem: Ah, sorry for that. I misunderstood. Maybe this is the time to admit that I am still running mistral on my own 770 (or maybe not)!! I believe I have fixed the .install files. Can a 770 user please let me know that click to install is now working for them (private mail will do -- no need to copy the list)? Graham ___ maemo-users mailing list maemo-users@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-users
Re: Battery Life
On 17/08/07, Eero Tamminen <[EMAIL PROTECTED]> wrote: > > Hi, > > ext Michael Thompson wrote: > > On 17/08/07, Eero Tamminen <[EMAIL PROTECTED]> wrote: > >> ext Frantisek Dufka wrote: > >>> True. But still seeing power consumption could help and having actual > >>> current drawn from battery somewhere in /proc would be very useful in > >>> many situations. > >>> > >>> > >>> These were just examples and some of them may not be good but you > should > >>> still see the point. > >> Yes, they are good points. Better tools are always needed. > >> > >> I'm just frustrated that people don't use the tools that > >> are already available, both on desktop[1] and for the device. > >> Even with the currency consumption meter you would still need top & > >> strace to find out which process actually consumes the power. > > > > So it turns out claws is doing a gettimeofday poll every 10 seconds, so > > you're right the strace was useful, but it's hard to quantify the affect > of > > this polling and whether it's significant enough to warrant the > developers > > fixing. > > 10 sec interval is not that bad. (LinuxThreads thread manager polls > at 8 sec interval in the devices i.e. all apps using threads poll in > the device, NPTL will fix that, but requires a new toolchain) > > If Claws would be using network at that interval or e.g. writing to > Flash, then it would definitely be bad. Also if it does that polling > when it's not visible (and updates screen?) when it's not visible, that > would also be bad. It happens when claws is minimised and set to off-line mode. I imagine it could be related to code to poll servers at some interval, but I haven't had time to look into it any further. ___ maemo-users mailing list maemo-users@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-users
Re: Battery Life
Hi, ext Michael Thompson wrote: > On 17/08/07, Eero Tamminen <[EMAIL PROTECTED]> wrote: >> ext Frantisek Dufka wrote: >>> True. But still seeing power consumption could help and having actual >>> current drawn from battery somewhere in /proc would be very useful in >>> many situations. >>> >>> >>> These were just examples and some of them may not be good but you should >>> still see the point. >> Yes, they are good points. Better tools are always needed. >> >> I'm just frustrated that people don't use the tools that >> are already available, both on desktop[1] and for the device. >> Even with the currency consumption meter you would still need top & >> strace to find out which process actually consumes the power. > > So it turns out claws is doing a gettimeofday poll every 10 seconds, so > you're right the strace was useful, but it's hard to quantify the affect of > this polling and whether it's significant enough to warrant the developers > fixing. 10 sec interval is not that bad. (LinuxThreads thread manager polls at 8 sec interval in the devices i.e. all apps using threads poll in the device, NPTL will fix that, but requires a new toolchain) If Claws would be using network at that interval or e.g. writing to Flash, then it would definitely be bad. Also if it does that polling when it's not visible (and updates screen?) when it's not visible, that would also be bad. Because you can have multiple processes running at the same time, and the device doesn't have anything that would sync these wakeups, it would be better that applications don't do extra wakeups. As a rule of thumb, if something wakes up more often than once every 1-2 secs, that's definitely something that has to be fixed. But basically I consider anything doing wakeups on its own broken, the wakeups should be event based, not timer based[1]. E.g. for monitoring files there's inotify (or earlier dnotify) and wrapper for that offered by gnome-vfs. [1] Something like clock is exception, but it wakes at ~1 min interval. Things like CPU meters could have dynamic wakeups, if nothing happens wake up (to check CPU state) less often (once every 5 secs?), and increase the frequency when CPU is busy (to once a sec?). Unfortunately there's no event to tell that CPU usage changed :-) > The power consumption of applications in the foreground should also be good > as users can set the keyboard lock with an application in the foreground. If application doesn't get user input, it shouldn't have anything to do. Applications should only react to events they receive. - Eero ___ maemo-users mailing list maemo-users@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-users
Re: Battery Life
On 17/08/07, Eero Tamminen <[EMAIL PROTECTED]> wrote: > > Hi, > > ext Frantisek Dufka wrote: > > True. But still seeing power consumption could help and having actual > > current drawn from battery somewhere in /proc would be very useful in > > many situations. > > > > > > These were just examples and some of them may not be good but you should > > still see the point. > > Yes, they are good points. Better tools are always needed. > > I'm just frustrated that people don't use the tools that > are already available, both on desktop[1] and for the device. > Even with the currency consumption meter you would still need top & > strace to find out which process actually consumes the power. So it turns out claws is doing a gettimeofday poll every 10 seconds, so you're right the strace was useful, but it's hard to quantify the affect of this polling and whether it's significant enough to warrant the developers fixing. The power consumption of applications in the foreground should also be good as users can set the keyboard lock with an application in the foreground. Michael ___ maemo-users mailing list maemo-users@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-users
Re: Visudo Help
Hrmmff... One of these days I'll stop embarassing myself ;) /usr/sbin I guess, but it's in my path when I'm root, so I just type visudo. If it's not there automatically, I can't think of what might have installed it. I did find this thread [1] on the ITT forums that shows others using it with no mention of where it came from, so I think it's a default item. [1] http://www.internettablettalk.com/forums/showthread.php?t=2180 I tried adding: export EDITOR="/bin/vi" to my /etc/profile and it didn't work. EDITOR was added to my user env variables, but not when I transfered to root. Probably if I setup /etc/sudoers to allow user to call visudo, it would work. I was, however, able to add that line to the /usr/sbin/gainroot and that DOES work.[2] So now I can just use visudo as root without declaring the EDITOR or VISUAL variables, first. [2] sudo gainroot vi /usr/sbin/gainroot #!/bin/sh -e trap exit SIGHUP SIGINT SIGTERM export EDITOR="/bin/vi" PATH=. --Paul On 8/16/07, Dr. Nicholas Shaw <[EMAIL PROTECTED]> wrote: > > Paul, I've made the changes but on my N800 there isn't visudo in /sbin. > That was one of the first places I checked. Did you install it manually? > If > so, where did you get it (or did you compile it manually?)? > > James, thanks for the suggestion! > Thanks, > > Nick. > > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of Paul Klapperich > Sent: Thursday, August 16, 2007 9:44 PM > Cc: maemo-users@maemo.org > Subject: Re: Visudo Help > > On 8/16/07, James Sparenberg <[EMAIL PROTECTED]> wrote: > > > > On this one visudo is not on the box but the real solution is don't > chmod > > the file. VI it as root, then instead of doing wq to quit (write quit) > do > > wq! (w q then exclamation point or more commonly known as bang) this > will > > override the read only aspect and commit your changes without running > the > > risk of forgeting to chmod > > > > James > > > > which is what I was driving at, but that won't protect against errors > as visudo will also. Visudo is in /sbin on the device. It works fine. > > --Paul > ___ > maemo-users mailing list > maemo-users@maemo.org > https://lists.maemo.org/mailman/listinfo/maemo-users > > ___ maemo-users mailing list maemo-users@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-users
Re: Battery Life
Hi, ext Frantisek Dufka wrote: > True. But still seeing power consumption could help and having actual > current drawn from battery somewhere in /proc would be very useful in > many situations. > > Even if I agree with things you said I still think your response is > influenced by the fact that Nokia hides such values from us (either > because it is not possible due to current hw design or because it thinks > such information is sensitive). > > I had iPAQ 3870 and there was such value available. It helped me a lot > (both as user and programmer) to understand what is the cost of having > some features enabled (playing audio, brightness on higher level, > bluetooth communication, cpu busy, reading from card, ...). > > Things are not black and white. Maybe sometimes something doesn't need > to be done. If you know the costs you may avoid some features or try to > optimize its usage in your application. If you don't know the > consumption then you can't optimize (both as user and developer). > > Examples of such optimizations: > > It is worthwhile to implement caching network data to mmc card while > playing media (i.e. read playlist ahead as fast as possible from > network) or is streaming on demand good enough? > > Does the brightness consumes as much as I expect? > > How much do I save when turning volume down? > > Does black theme save power? AFAIK no (unless you mean switching the display off :)). Igor? > These were just examples and some of them may not be good but you should > still see the point. Yes, they are good points. Better tools are always needed. I'm just frustrated that people don't use the tools that are already available, both on desktop[1] and for the device. Even with the currency consumption meter you would still need top & strace to find out which process actually consumes the power. It's not necessary that the application developers themselves use the tools (they are busy developing their applications), but the (power :)) users can use these tools also. - Eero [1] E.g. gnome power manager was something horrible when I last straced it on Ubuntu, it was constantly polling... I later noticed that it was mentioned also on the powertop page. ___ maemo-users mailing list maemo-users@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-users
Re: Battery Life
Eero Tamminen wrote: > You use extra hardware for that, not software. :-) Extra hardware may not be needed. > But anyway, that is not really relevant information when talking > about applications. The question is not how much doing a thing > consumes power, but is doing that thing really something that needs > to be done. True. But still seeing power consumption could help and having actual current drawn from battery somewhere in /proc would be very useful in many situations. Even if I agree with things you said I still think your response is influenced by the fact that Nokia hides such values from us (either because it is not possible due to current hw design or because it thinks such information is sensitive). I had iPAQ 3870 and there was such value available. It helped me a lot (both as user and programmer) to understand what is the cost of having some features enabled (playing audio, brightness on higher level, bluetooth communication, cpu busy, reading from card, ...). Things are not black and white. Maybe sometimes something doesn't need to be done. If you know the costs you may avoid some features or try to optimize its usage in your application. If you don't know the consumption then you can't optimize (both as user and developer). Examples of such optimizations: It is worthwhile to implement caching network data to mmc card while playing media (i.e. read playlist ahead as fast as possible from network) or is streaming on demand good enough? Does the brightness consumes as much as I expect? How much do I save when turning volume down? Does black theme save power? These were just examples and some of them may not be good but you should still see the point. Frantisek ___ maemo-users mailing list maemo-users@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-users
Re: how to install GPE Calendar?
"ext Graham Cobb" <[EMAIL PROTECTED]> writes: > "Click to install" doesn't work on the 770. It works 'somwewhat'. The Application Manager will silently ignore files that are not compatible with the 770 instead of complaining loudly. (I don't really remember if there was a good reason for this or if I just screwed up. I guess I just screwed up. But then again I didn't expect that version of the AM to stick around for so long...) But, downloads.maemo.org claims that GPE Calendar works with both IT OS 2007 and IT OS 2006, so the .install file should have entries for both. It only has one for IT OS 2007, tho, and that is the problem: [install] repo_name = GPE main repo_deb_3 = deb http://www.cobb.uk.net/apt/ bora user package = gpe-calendar > You have to add the repository to the Application Manager by hand. > In the Application Manager, use the Tools/Application > catalogue... menu item and add a new catalogue. If you go to > http://www.cobb.uk.net/770 you will see the details you need to > enter (you want the "gregale" distribution). Then the .install file should look like this: [install] repo_name = GPE main repo_deb= deb http://www.cobb.uk.net/apt/ gregale user repo_deb_3 = deb http://www.cobb.uk.net/apt/ bora user package = gpe-calendar Graham, can you relay that information to the right people? ___ maemo-users mailing list maemo-users@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-users
Re: Battery Life
Hi, > ext Michael Thompson wrote: >> How do we know if an application has good power usage. It wakes up only when it's doing something for you. When it _does_ things for you, it has good responsiveness and doesn't make rest of the system non-responsive. >> How do we know what the actual current consumption is? You use extra hardware for that, not software. :-) But anyway, that is not really relevant information when talking about applications. The question is not how much doing a thing consumes power, but is doing that thing really something that needs to be done. If application has to do something, then it has to. The power consumption of doing something isn't anything that application developers can affect (people at Nokia side are trying to get HW/kernel such that when something is not used, it doesn't use more power than it absolutely has to). If code doesn't need to do anything, then it shouldn't. This is the same crap people talk about in memory analysis. They want to know how much _exactly_ something is using from the whole system compared to the other applications. But that's not really a relevant question. The relevant questions are: - Is the application able to do what it needs to do? Even when user has other applications open with data he cares about? - basically how much free memory is available in the system - Is there something that can be optimized in the (memory/power/cpu) usage? - often there's also a performance/memory tradeoff If there isn't anything that you can optimize, it doesn't matter how exact number you get for the consumption. Getting a relatively good approximation helps in prioritization, but it doesn't need to be necessarily be particularly accurate. >> Does the hardware know what current is being consumed from the battery >> (and can that info be exposed in/proc or the battery applett) or is >> the battery app guessing based on the battery voltage? Igor Stoppa wrote: > There is ongoing work to provide users with graphical information about > current consumption. So the device _can_ know (fairly exactly) how much power it draws from the battery at the moment? > The idea is that when you want to measure an application, you can first > do a sort of "calibration" with a clean system in the state you are > interested (i.e. wlan on or off), then install the application to be > tested and run gain the measurement. This value changes the whole time depending on what application is doing, user's settings (wlan power, timeouts etc). How accurate average the device can get on the power it spends? >> I'm not sure that strace'ing is very ideal > > No, but some users and most developers could use it. > >> Powertop is not using such hacks and it works. Users have >> started >> complaining with dfevelopers and developers themselves have >> taken >> powerto in use. >> >> Can we run powertop or equivalent on the N800/Maemo? > > I'll let Eero answer this. The kernel needs to be re-built with CONFIG_TIMER_STATS=y but that seems to make at least the current wlan driver (binary blob) not to work correctly. The powertop package from Debian should work about as is once timer stats are provided. However, it should be noted that for a normal developer strace provides *much* better information. The problem with powertop is how you exclude the wakeups your powertop usage causes (ssh wlan wakeups etc)? You can just output the powertop data to tmpfs, but that's also very user unfriendly way to get the information. With strace you can monitor exactly what you want. If a process is not doing any syscalls (nor busylooping without syscalls which would show up immediately in "top"), it doesn't invoke anything from the kernel either, so getting information about kernel when you're interested just about what user-space processes cause, is redundant. Third tool you can use in addition to "top" and "strace" is "xresponse". It tells what screen updates are being done to the screen. Just do this in the ssh console: xresponse -w 0 -i And see all the screen updates (in X geometry format) listed with their timestamps. Xresponse and strace are available from the Maemo repositories. With Sbox you can just "kill -SIGUSR1 $(pidof Xephyr)" to request Xephyr to show which parts of its screen are updated. Note that both Xephyr and xresponse can show multiple screen updates that happen at the same time as a single rectangle. That's due to XDamage extension works, not a problem in the tools themselves. - Eero ___ maemo-users mailing list maemo-users@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-users
