Re: Not enough memory
Eero Tamminen wrote: >Err? >UBIFS used for rootfs is most certainly using compression. Wow... totally missed that. I haven't hacked around with it to that level, and missed it in the df listing some how. :P Yes, that does present challenges, but nothing that can't be overcome with some clever scripting. >Sorry, you lost me. >Where you're expecting this proposed package space estimationto happen and >when? I would prefer to see it pre-install, with the info being sent to the App Manager using the same mechanism that's providing the details it gets now. It's getting package names, sizes, descriptions and the like from somewhere already. Tacking on more info should be pretty trivial, even if it's a pre-tack into the description text by a build script. It could (as I noted) be collected during install and show up in the package removal screen. It wouldn't be an up-front warning, but at least it would be something. It would also be more accurate, since it's post fact and monitoring _actual_ usage on the device. It would take into account things like compression, install script actions, link routing, dependent packages, etc. >> it's not saying it will take 17,367,483 bytes; it says "17.4M". > >Which I think is too accurate number when the things I mentioned are taken >into account. :-) So you're advocating the user have no idea how large a package is? Not giving any details or hints as to how large it would be? What would you propose? "Big", "Medium", and "Tiny"? >Well, you're free to suggest such an UI change, but I have my doubts about how >well less-technical users understand the distinction between rootfs and /home >etc. That's the issue right now! The user doesn't have a distinction between rootfs and home. Then they get a message when trying to update that they "need more memory" on their rootfs. So they go into application manager, look for large packages, delete them, and still get told they need more space. That's because app manager right now only shows total package space, which is useless for this task. If the UI for uninstall showed how much each package (rough estimate) took in rootfs, the average user could make much better choices about what to uninstall to do updates. Again, this is to help less technical users. If they're expected to clear space on the rootfs to do updates, there should be a tool to show how much each package takes on the rootfs. The app manager is the clear choice to do this, since it can collect such data easily and is the tool most users will go to in order to delete apps to free up space. >That hypothetical 3rd party application could show also those and nothings >preventing it from implementing package removal too. Yes, that's great. So let's re-implement the entire code base from app manager to find/list/catalog installed packages. Then hook into the actual app manager to figure out when it's installing things so we can do a pre/post snapshot during installs. Store that data in a separate place, and present it in a separate UI. Push this app through devel, then testing, then _maybe_ get it to Extras. And finally, start a mass campaign to educate people that this new tool exists, and that they need to install it (with App Manager) so they can then use to find this small piece of information they need for when updates come out and they are told they need more rootfs. Or, we could just add few lines of code to app manager to do a df pre/post, store the extra 4 bytes on rootfs usage in it's database, and show that data in 5 to 10 characters on the existing package removal UI, which everyone has installed and already knows how to use. And it will update automatically on 95% of the devices when released, either separately or as part of a PR update. Which do you think would be easier and more effective to do? To me, app manager is the clear choice. > That would include also their dependencies, but those could be shared between > later installed packages. No solution will be 100% perfect. Nobody is asking for a 100% perfect solution that will take all things into account. All that is being asked is a simple _estimate_ of rootfs usage per package. Knowing that ioQuake and Angry Birds are both 68M is useless data for freeing rootfs space. Knowing that ioQuake takes 35M in rootfs, where Angry Birds only takes 1M on rootfs is much more useful, even if those numbers are 30% off actual space usage. Do you see the point I'm making? >And what about the non-UI packages that aren't shown in the Application >manager UI (for a good reason) and which also take space? With the exception of lage non-optified packages (like python or qt devel packages) most CLI packages are super tiny. Realistically, if implemented in app manager as discussed above, the first package that installs a large non-optified CLI package will still show that it used a ton of rootfs space. At least there's a
Re: Not enough memory
Hi, ext Craig Woodward wrote: Eero Tamminen wrote: Compression can make normal ASCII data into 1/3 of its size Yes, wonderful. Is a default N900 using a compressed filesystem? NO. Why are we talking about it? Moot point. Err? UBIFS used for rootfs is most certainly using compression. For example the 20MB icon cache file (which is generated so it's not in any package) that was earlier the largest issue for SSUs (due to Gtk keeping old versions open) and which we removed for PR1.1, took "only" 3MB of the rootfs space per instance. Btw. In case you're interested, here are the technical details which explain why even the file system itself cannot give very good estimate on how much "free space" it has: http://www.linux-mtd.infradead.org/doc/ubifs.html#L_spaceacc And the issue with that is that package doesn't know into which Fremantle release it's going to be installed. Doesn't the package manager send some kind of identifying info? Sorry, you lost me. Where you're expecting this proposed package space estimation to happen and when? When creating a package? Before installing it? After it's installed? If it's before install, what would provide that information to device? [...] it's not saying it will take 17,367,483 bytes; it says "17.4M". Which I think is too accurate number when the things I mentioned are taken into account. :-) [..] I think it's a bit too confusing to have on the Application Manager UI. I disagree. It think it's absolutely needed in the package manager, especially when the app manager is telling users "insufficient rootfs space" when trying to do PR updates. /home is larger, but it can also run out of space. Root running out of space is more important though because if it becomes full (so that even root cannot write anything there), the system may not anymore boot up. /home partition becoming full means that applications may not behave correctly (tracker cannot index new files, so media player doesn't show them, email cannot be fetched etc). The app manager is the default tool they're going to use to install and remove packages. Knowing how much space a package takes up on the rootfs is critical in selecting which packages to remove to make space for such an update. Removing a non-optified 8M package is going to free a lot more space on the rootfs than removing an optified one that shows 60M of usage. But you have to be able to tell if it's optified or not, which right now there's no way of telling. > Maybe there could be a separate 3rd party application That would be great too, but having it in the app manager would make it that much easier. It's one small piece of metadata, a few bytes per package. Well, you're free to suggest such an UI change, but I have my doubts about how well less-technical users understand the distinction between rootfs and /home etc. I assume you're suggesting that these values would be shown in the UI always? Even if it's collected during install (doing a df pre/post and storing that per block device), it's something. That would include also their dependencies, but those could be shared between later installed packages. Nothing but the app manager can do that though, since it's the one doing the installs. And really, nobody wants to hop from one app to the other to find/delete rootfs hogs. And what about the non-UI packages that aren't shown in the Application manager UI (for a good reason) and which also take space? That hypothetical 3rd party application could show also those and nothings preventing it from implementing package removal too. - Eero ___ maemo-users mailing list maemo-users@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-users
Re: Not enough memory
Eero Tamminen wrote: >Compression can make normal ASCII data into 1/3 of its size Yes, wonderful. Is a default N900 using a compressed filesystem? NO. Why are we talking about it? Moot point. >And the issue with that is that package doesn't know into which Fremantle >release it's going to be installed. Doesn't the package manager send some kind of identifying info? Let's assume it doesn't. Again, we're talking about estimates for the default use case. 90% or more N900 users are going to be using a rather standard system, with the latest firmware base. If they've re-partitioned their memory, or linked things around, or are still on PR1.0, then they should be monitoring things closer already. >If extras www-pages are going to have something like this, I would recommend >it to round the numbers at least to MBs and empathize that it's an estimate... The app manager already does. When I go to install a package, it's not saying it will take 17,367,483 bytes; it says "17.4M". All that's being asked is for it to now say: 17.4M (1.6M rootfs) or 17.4M (12.2M rootfs) so we can tell if it's a rootfs hog. Right now "17.4M" doesn't tell us it's a optified package or not, and gives little clue as to how it will impact the system. Even just the addition of an _estimated percentage_ for rootfs usage makes it very clear if a package is optified or not, as with the example above. >I think it's a bit too confusing to have on the Application Manager UI. I disagree. It think it's absolutely needed in the package manager, especially when the app manager is telling users "insufficient rootfs space" when trying to do PR updates. The app manager is the default tool they're going to use to install and remove packages. Knowing how much space a package takes up on the rootfs is critical in selecting which packages to remove to make space for such an update. Removing a non-optified 8M package is going to free a lot more space on the rootfs than removing an optified one that shows 60M of usage. But you have to be able to tell if it's optified or not, which right now there's no way of telling. >Maybe there could be a separate 3rd party application That would be great too, but having it in the app manager would make it that much easier. It's one small piece of metadata, a few bytes per package. Even if it's collected during install (doing a df pre/post and storing that per block device), it's something. Nothing but the app manager can do that though, since it's the one doing the installs. And really, nobody wants to hop from one app to the other to find/delete rootfs hogs. ___ maemo-users mailing list maemo-users@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-users
Re: Not enough memory
On 19 February 2010 22:16, Craig Woodward wrote: > One good example for why is that the main package is really just a big > dependency list of other packages to pull. If beta versions exists in devel > and you update with that repository on, it may pull a beta package over a > stable one, since it's version is "newer". Not to mention namespace > conflicts. This is a useful warning; The "newer" dependency problem can be negated by using apt pinning: http://jaqque.sbih.org/kplug/apt-pinning.html I *think* (not tried it yet because I'm still waiting for my OTA update) that you can also configure the maximum cache size used by APT which may help it it play nicer with rootfs. Ed. ___ maemo-users mailing list maemo-users@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-users
Re: Not enough memory
Hi, ext Craig Woodward wrote: As for the rest, the tools certainly can know where the files are going. The paths are stored in the package, and a simple test-extract will tell you the paths and rough size of a file. I think dpkg tools check the size before packaging the data, whereas latest maemo-optify thing seems to be doing things in postinst i.e. after installation (not just extraction). A simple pearl script could be setup to tally the counts based on the default N900 mounting layout, build a percentage, and show how much is root vs opt vs ... No, you can't show what it will take for a compressed file system, Compression can make normal ASCII data into 1/3 of its size, binary data like libs, maybe to 2/3 of their size, already compressed files (like PNGs and MP3s) aren't affected. Removal of docs can have also a very large effect, but most packages don't have that much docs compared to rest of the package contents size. If this kind of testing is done elsewhere than on device, corresponding package files can be just compressed with LZO to see their compressed size (on device the files will take a bit more, but this is a good approximation). Here's even a script to do it: https://bugs.maemo.org/attachment.cgi?id=1510 or one that's been linked differently. But even a rough idea for a *standard* N900 setup would be nice. That can change between releases (I think think it will in next release, more stuff moves to eMMC to make SSU easier). And the issue with that is that package doesn't know into which Fremantle release it's going to be installed. If a package moves things or unpacks things during it's install, well... that's unavoidable, and again is _already_ not showing up in the usage estimate we're getting now. I think you're just taking this a little too literally. Nobody is asking for exact numbers for all scenarios. People just want a little more detail on how the existing estimate breaks down when it comes to rootfs vs storage. Nobody is expecting it to work to the byte, but for most packages it's going to give a pretty good idea of how much space it will take, and make it much clearer which packages have been optified vs which ones have not. If extras www-pages are going to have something like this, I would recommend it to round the numbers at least to MBs and empathize that it's an estimate... As to SSUs, its the package manager that should give this kind of information, but I think it's a bit too confusing to have on the Application Manager UI. Maybe there could be a separate 3rd party application for the device which goes through all packages, checks where they've installed their files & how large they're and shows this information sorted by the size taken from different partitions so that user knows which packages to uninstall to get most space. But that doesn't help if the disk issue isn't from files installed by packages, but them being open, or there being cache files (for apt etc)... - Eero Fixing of this mess is hopefully something that can be backported from Harmattan to Fremantle after Harmattan is released... ___ maemo-users mailing list maemo-users@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-users
Re: Not enough memory
Hi, Hamalainen Kimmo (Nokia-D/Helsinki) wrote: On Fri, 2010-02-19 at 11:02 +0100, Tamminen Eero (Nokia-D/Helsinki) ext Jason wrote: On a more technical, get-it-done approach, my problem with OOM was too much crap in /var/cache/apt/archive/ . There are two ways to handle this in a more user friendly manner. Instead of the OOM error message, offer to run 'apt-get clean', and/or symlink /var/cache/apt out to /home/.var.cache.apt . Which I just tried, and seems to wfm. $ sudo gainroot # cd /var/cache/ # mv apt /home/.var.cache.apt # ln -sf ../../home/.var.cache.apt apt AFAIK: * Application manager doesn't have caches on rootfs, but on the 2GB partition. Apparently it still has them on rootfs, see the internal bug 144371. That bug is about using apt directly, not application manager. It's the same as this public one: https://bugs.maemo.org/show_bug.cgi?id=5746 I don't see it necessary to keep these caches on rootfs since the .deb cache is not mandatory and the rest (.bin files) can be regenerated anytime. - Eero ___ maemo-users mailing list maemo-users@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-users
Re: Not enough memory
Eero Tamminen wrote: >It cannot, for several reasons. >The ... metadata is ... based on ... space .. which may be block based, >unlike UBIFS. I don't think anyone is going to care if it's off by 5 to 10%, since that's already the case. The existing estimates are usually off for many of the reasons you state already, who cares if the breakdown is off a little? As for the rest, the tools certainly can know where the files are going. The paths are stored in the package, and a simple test-extract will tell you the paths and rough size of a file. A simple pearl script could be setup to tally the counts based on the default N900 mounting layout, build a percentage, and show how much is root vs opt vs ... No, you can't show what it will take for a compressed file system, or one that's been linked differently. But even a rough idea for a *standard* N900 setup would be nice. If a package moves things or unpacks things during it's install, well... that's unavoidable, and again is _already_ not showing up in the usage estimate we're getting now. I think you're just taking this a little too literally. Nobody is asking for exact numbers for all scenarios. People just want a little more detail on how the existing estimate breaks down when it comes to rootfs vs storage. Nobody is expecting it to work to the byte, but for most packages it's going to give a pretty good idea of how much space it will take, and make it much clearer which packages have been optified vs which ones have not. ___ maemo-users mailing list maemo-users@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-users
Re: Not enough memory
Johan Helsingius wrote: >One that, as you yourself point out, can easily be fixed at no cost. All I am >saying is that it *should* be fixed. If I'm reading some of the replies here correctly, it looks like they have done some of this in PR1.1.1, so this may be the last time we have this issue? Personally, I think it's better to turn off devel and testing before doing an update in any case. One good example for why is that the main package is really just a big dependency list of other packages to pull. If beta versions exists in devel and you update with that repository on, it may pull a beta package over a stable one, since it's version is "newer". Not to mention namespace conflicts. I don't think most people having this issue are having it because they have repositories just enabled though. It's usually because they've installed a bunch of things from the repositories that are devel-level and eat lots of space on the rootfs. I've only "optified" my themes directory by hand, and pulled the optified python package. Between that and turning off the repositories for the update I had well over 70M free on the root, and I have plenty of devel/testing software installed. (fMMS, Haze, games, Stelarium, pidgin, Joikuspot, several widgits...) Yes, there at lots of things I think Maemo can fix to help this, and I think they are doing it rather quickly (4 releases in 4 months is an aggressive release cycle). Just looking at what the community has done to help others update and implementing those changes would be a great start. Moving themes, icons, apt caches, and the like off to /opt space and linking them over could be a simple update bundled with the rest of the stuff. But that's not going to fix the world if people keep blindly installing devel apps and not knowing or caring if they're optified yet. We need to get these ideas to Maemo to fix them, but we also have to push to educate average users who aren't paying attention to the exiting warning signs. Just complaining that you have to enter commands to move things around isn't helping. Promoting ideas of what to change, how to better warn/educate users, pushing solutions in the brainstorm area, and the like are much more productive means to that end that complaining about it every month in a user e-mail forum. ___ maemo-users mailing list maemo-users@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-users
Re: Not enough memory
"Tamminen Eero (Nokia-D/Helsinki)" writes: > AFAIK: > > * Application manager doesn't have caches on rootfs, but on >the 2GB partition. > > * However, if you use apt _directly_, you need to tell it to >use 2GB partition for its caching like application manager does. There are a number of caches involved, and I don't know the latest information about where they are unfortunately. Some of them got moved around recently, I think. The caches are: /var/lib/apt/lists/ - Packages and Release files from the repos. /var/cache/apt/ - 'compiled' binary representation of above /var/cache/apt/archives - downloaded packages ___ maemo-users mailing list maemo-users@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-users
RE: Not enough memory
I did something similar below, and it worked a little bit, but I eventally ran out of room again. What I ended up doing was mkdir /opt/cache mkdir /opt/lib cd /var/cache mv apt /opt/cache ln -s /opt/cache/apt apt cd /var/lib mv apt /opt/lib ln -s /opt/lib/apt apt mv dpkg /opt/dpkg ln -s /opt/lib/dpkg dpkg At present /opt/cache/apt is 10 Meg, /opt/lib/apt is 18, meg and /opt/lib/dpkg is 28 Meg With 56 Meg moved out of rootfs, I now have 30 Meg to spare in my rootfs Aldon -Original Message- From: maemo-users-boun...@maemo.org [mailto:maemo-users-boun...@maemo.org]on Behalf Of Kimmo Hämäläinen Sent: Friday, February 19, 2010 6:23 AM To: Tamminen Eero (Nokia-D/Helsinki) Cc: maemo-users@maemo.org Subject: Re: Not enough memory On Fri, 2010-02-19 at 11:02 +0100, Tamminen Eero (Nokia-D/Helsinki) wrote: > Hi, > > ext Jason wrote: > > On a more technical, get-it-done approach, my problem with OOM was > > too much crap in /var/cache/apt/archive/ . There are two ways to > > handle this in a more user friendly manner. Instead of the OOM > > error message, offer to run 'apt-get clean', and/or symlink > > /var/cache/apt out to /home/.var.cache.apt . Which I just tried, > > and seems to wfm. > > > > $ sudo gainroot > > # cd /var/cache/ > > # mv apt /home/.var.cache.apt > > # ln -sf ../../home/.var.cache.apt apt > > AFAIK: > > * Application manager doesn't have caches on rootfs, but on >the 2GB partition. Apparently it still has them on rootfs, see the internal bug 144371. I don't see it necessary to keep these caches on rootfs since the .deb cache is not mandatory and the rest (.bin files) can be regenerated anytime. -Kimmo ___ 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: Not enough memory
On Fri, 2010-02-19 at 11:02 +0100, Tamminen Eero (Nokia-D/Helsinki) wrote: > Hi, > > ext Jason wrote: > > On a more technical, get-it-done approach, my problem with OOM was > > too much crap in /var/cache/apt/archive/ . There are two ways to > > handle this in a more user friendly manner. Instead of the OOM > > error message, offer to run 'apt-get clean', and/or symlink > > /var/cache/apt out to /home/.var.cache.apt . Which I just tried, > > and seems to wfm. > > > > $ sudo gainroot > > # cd /var/cache/ > > # mv apt /home/.var.cache.apt > > # ln -sf ../../home/.var.cache.apt apt > > AFAIK: > > * Application manager doesn't have caches on rootfs, but on >the 2GB partition. Apparently it still has them on rootfs, see the internal bug 144371. I don't see it necessary to keep these caches on rootfs since the .deb cache is not mandatory and the rest (.bin files) can be regenerated anytime. -Kimmo ___ maemo-users mailing list maemo-users@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-users
Re: Not enough memory
Hi, ext David Greaves wrote: ext Jan Knutar wrote: Another nice feature would be if the application manager, or a web interface somewhere, could tell you beforehand how much space an app consumes on /... It cannot, for several reasons. The size for the package included to the binary package metadata is determined by the Debian tools based on the space how much these files take on the build file system which may be block based, unlike UBIFS. And more importantly, these tools don't or even cannot take into account: 1. Where the files go, root or /home i.e. how much space package will take from which file system. 2. If it goes to a compressed file system (like root), what is the compressed size. The compression level used when mounting the partition affects this too (which can be changed by root user). 3. Which of the installed files will be removed by apt-hooks on the device (e.g. docs...). User can install also his own hooks. 4. Will the package itself do something that affects the space, like: - moving files from one partition to another - adding / generating new files - removing files Even larger issue is with updates. When updating a file that is in use, file system cannot get rid of the old version of the file until all of its users close the old file (which happens e.g. at reboot). And if the release image was compressed with different compression level than what is used at run-time (may be lower for performance reasons), even copying the same file in place may increase disk usage. Application manager doesn't have any reasonable way to find out about this (and the comments above apply also to this space). That too would be useful. Not as much as if the app manager didn't takes >10Mb of space for repo indexes The files are fairly repeatable ASCII. Rootfs compresses them pretty well, you should check the lzo compressed size. - Eero ___ maemo-users mailing list maemo-users@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-users
Re: Not enough memory
Hi, ext Jason wrote: On a more technical, get-it-done approach, my problem with OOM was too much crap in /var/cache/apt/archive/ . There are two ways to handle this in a more user friendly manner. Instead of the OOM error message, offer to run 'apt-get clean', and/or symlink /var/cache/apt out to /home/.var.cache.apt . Which I just tried, and seems to wfm. $ sudo gainroot # cd /var/cache/ # mv apt /home/.var.cache.apt # ln -sf ../../home/.var.cache.apt apt AFAIK: * Application manager doesn't have caches on rootfs, but on the 2GB partition. * However, if you use apt _directly_, you need to tell it to use 2GB partition for its caching like application manager does. Marius can maybe confirm this. - Eero ___ maemo-users mailing list maemo-users@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-users
Re: Not enough memory
Craig, > Again, from my understanding, the flash memory is split up > because it's slightly different hardware wise. The first > chunk is a higher class meaning it has faster access, while > the larger chunk is slower. If that's true, it makes sense > that it was partitioned out this way. You might be right about the hardware, and in that case, yes, it would make sense to put the frequently-used files on a smaller piece of faster but more expensive memory. But the application manager / apt is not a frequently used application. I do not care if checking for new updates takes 10 or 20 s. So if you are right, the original partitioning decisions are even worse than I thought - wasting precious fast memory on stuff that definitely doesn't need the speed. > I take no exception to saying it's a poor design choice > (IN YOUR OPINION) that they didn't go with a device with > full class 6 flash I am not talking about hardware design, but a very simple software/set-up choice. One that, as you yourself point out, can easily be fixed at no cost. All I am saying is that it *should* be fixed. Julf ___ maemo-users mailing list maemo-users@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-users
Re: Not enough memory
Let me preface this by saying that personally, I hope you continue to "tinker" with your device, in fact I encourage it _if you have the time_. It's fun to do, and does help the community if you're feeding back ideas and bugs. But if you decide to "tinker" with it, PLEASE don't come here and whine about what a pain it is that you have to "tinker" with it again before you can update to the latest firmware. It doesn't help or add to anything, and after a while just becomes annoying. Christian Walther wrote: >I hope that what you're saying and implying is not the attitude of the general >Maemo developer I don't work for, nor claim to be affiliated with Maemo in any way. My opinions are my own. You'll note I don't even have a garage setup, so where you're getting the idea that I'm a Maemo developer, I'm not sure. >What I have to think about is ... Don't put words in my mouth. I've never said "extras-devel is a piece of crap". I said if you installed random software from random repositories (checking a box every time to override the system trying to warn you), that YOU are responsible for your actions. You spoke about the N900 being an "ecosystem", and I simply followed your analogy noting that in an ecosystem even animals are smart enough to know how to avoid stepping in their own mess. >My plan was to install the Apps I needed, to give them a try, lend helping hand An admirable thing, which I do this as well. The difference being I actually noticed and read the huge red warning label attached to the page indicating how to setup the devel repository. It clearly states that because this software is development level, it may cause problems, up to and including bricking the device. Having to make adjustments to update later clearly falls in the range of "up to bricking your device". When PR1.1 came out and I needed to free up space on the rootfs, I went looking for how to do it. I simply fixed the issue, without feeling the need to post to a mailing list how terrible the device is or knock the quality control of the company releasing the software. >But reality is that I have a life full of responsibilities: I see, and you think I'm an orphan, living in a care home and have no life? If you did a poll you'd find it's rare to find others here that don't have a job and/or a family to support. My N900 is much lower on the list than #3. I personally have done little development for the N900 because I work with almost identical devices every day at work. After 8 or 9 hours of work the last thing I want to do is come home and do more work on yet another micro device. I've done some tweaking, but not much coding outside of a couple scripts here an there, and writing a couple bugs or brainstorm voting. > sometimes I just want to use my phone. So, you see, in my eyes installing a > package is trivial, and nobody should have to check how much memory a package > consumes. Wow... That's a leap if I've ever seen one. Just because you "want to use your phone" doesn't mean installing a package is trivial OR that you shouldn't have to check how much memory it consumes. It's like saying "Sometimes I just want to drive my car. Fueling it should be free, and I should never have to look to see how much gas I have in my car." And let's not mix eggs here. We're not talking about "installing a package". We're talking about updating the operating system and key components that make the whole device run. The fact that it's updateable OTA without re-flashing/installing is a testament to how far Maemo, Debian, and mobile computing has come. Most "phones" still update via flash upgrade, only at a customer service center, and typically nuke contact lists, downloaded apps and tones in the process. >Hey $user, we packaged a few cool apps that are even shown on youtube To my knowledge, neither Nokia nor Maemo has "packaged cool apps" and shown them on youtube that cause your rootfs to fill up. There are lots of other groups that have, but not the people that made the device or are releasing the software updates. In fact, both explicitly go out of their way to warn you that installing anything outside of the Extras repository and/or the OVI store can seriously compromise your device, and it's ability to function, yet alone upgrade your base OS and key system components. I direct you again to the check box and warning that pops up for almost every app install. > there are even Nerds out there who do not want to tinker around with their > [phone]. And my eyes, they shouldn't have to. And they (and you) don't have to! You don't have to install things from devel or testing, or third party repositories. You don't have to buy a N900 for that matter. Nobody's *forcing* you to do any of this. You are *choosing* to install things, and to "tinker" with your phone. If you hadn't done that, the update would have worked just fine! When you choose
Re: Not enough memory
Johan Helsingius wrote: >one of the things that really put me off the Apple stuff is the fanboy >religiousness. I'm far from a Nokia "fan-boy", this being my second Nokia device owned ever. There are plenty of things I dislike about the N900, and about previous micros/tablets/phones I've owned. I'm not "defending" Nokia. I'm simply pointing out WHY things are the way they are, and asking that we not have this massive whine-fest every time an update comes out and people have issues because they've installed devel level software that makes it hard to update. Again, from my understanding, the flash memory is split up because it's slightly different hardware wise. The first chunk is a higher class, meaning it has faster access, while the larger chunk is slower. If that's true, it makes sense that it was partitioned out this way. (If not, why not re-partition your phone and re-flash? The tools exist, and it would be a one-time hit.) Having worked with micro devices for most of the past 20 years, I can tell you the space assigned is PLENTY for what this device is designed to do. More importantly, had the entire memory block been setup as class 6 or better, it would have likely increased the cost of the device significantly. >Sorry, as someone who has been involved with first UNIX and then Linux for the >last 30 years... I work in the micro controller field, and have for decades at small and large firms (including Xerox and NorTel). I won't get into the "who's disc is bigger" argument with you beyond that, but fair to say we're probably both qualified to talk about the issues at hand. I take no exception to saying it's a poor design choice (IN YOUR OPINION) that they didn't go with a device with full class 6 flash, and charged as much as an iPhone for their device. But coming from working with devices with 1/100th the amount of memory, I can tell you from where I sit this looks like a trivial issue. Nokia made a performance/cost trade off which software is working with the best it can. Claiming that the trade off was a poor choice is perfectly acceptable. Harping on it every time an update comes out, despite all the warnings, and having obvious solutions and work-arounds being publicly known for months now is whining. ___ maemo-users mailing list maemo-users@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-users
RE: Not enough memory
Yes, moving the package cache and other parts of the packaging system out of rootfs works great. It is, perhaps, a little geeky for some users, but for those comfortable with root access at a command line it is trivial. I wrote about it in a blog post when the last big set of upgrades came out #n900 updates http://www.orient-lodge.com/node/3920 In my case, I have tons of junk so I moved three directories, /var/lib/apt /var/lib/dpkg /var/cache/apt I haven't had problems since. Aldon -Original Message- From: maemo-users-boun...@maemo.org [mailto:maemo-users-boun...@maemo.org]on Behalf Of Gunter Ohrner Sent: Thursday, February 18, 2010 3:16 PM To: maemo-users@maemo.org Subject: Re: Not enough memory Nelson Ferreira wrote: > 4. Allow for the package cache to be out of rootfs I did not receive my recently ordered N900 so far, but can't you transparently move the apt cache (and other larger directories) somewhere else using a bind mount? I'd assume most things in /var/cache, /var/spool (if it exists) and /var/lib do not need to reside on the "/" partition. Greetings, Gunter ___ 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: Not enough memory
Nelson Ferreira wrote: > 4. Allow for the package cache to be out of rootfs I did not receive my recently ordered N900 so far, but can't you transparently move the apt cache (and other larger directories) somewhere else using a bind mount? I'd assume most things in /var/cache, /var/spool (if it exists) and /var/lib do not need to reside on the "/" partition. Greetings, Gunter ___ maemo-users mailing list maemo-users@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-users
Re: Not enough memory
Craig, > If you wanted an iPhone, you should have bought one. Sorry, that is the most pitiful excuse I have heard for someone screwing up the partitioning. Yes, the N900 is intended for technically sophisticated users. No, that doesn't mean every single issue can be written off as "user error". It is funny that you refer to the iPhone, because one of the things that really put me off the Apple stuff is the fanboy religiousness. So, could we please not have Nokia fanboys either - a screw up is a screw up. > this is not a computer for someone that don't know > how to maintain a computer. Sorry, as someone who has been involved with first UNIX and then Linux for the last 30 years, I like to think I know a thing or two about maintaining a computer. Some users, even fairly sophisticated ones, like to hold developers responsible for really bad design choices. That doesn't mean we think the whole product sucks, but some people seem to take any criticism as an attack to their beloved platform. Sometimes mistakes do need to get pointed out, even in an otherwise great product. If you can't handle it, stick to the fan club for 12 and under from now on. Julf ___ maemo-users mailing list maemo-users@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-users
Re: Not enough memory
Hi, On 18 February 2010 00:01, Craig Woodward wrote: [...] I hope that what you're saying and implying is not the attitude of the general Maemo developer, because it would mean that I've really chosen the wrong platform. What I have to think about is the fact that the maemo.orgs extra-devel repository is obviously "a random piece of crap", something I didn't now. You see, I perfectly well knew that the N900 is targeted towards tech savvy users, and that Maemo 6 is probably the first version being something for the average user. I knew that the amount of apps available isn't that high, and that many of them aren't even fully and properly "hildonized". That didn't keep me from buying the phone. You know why? Because it was clear to me that I wanted to be part of the maemo community. I'm not a developer, I don't know how to program in C++, and honestly, I don't want to learn this language, and neither do I want to learn python. You know what I did? I joined the maemo.org mailing lists the day I received my N900, since then I'm lurking around here, reading the discussions. I installed scratchbox on my laptop, and in fact ditched my lovely BSD install and settled on ArchLinux because of this. The N900 is my only phone, mainly because I can't afford buying a second one for everyday use, and I just don't like carrying around two handsets anyway. My plan was to install the Apps I needed, to give them a try, lend a helping hand to squash out bugs. That being said, I even accepted that the apps I installed contained bugs, something I'm fine with as long as there's some constant development. But reality is that I have a life full of responsibilities: I have a work life (like most of you I think), and I have (and want) to care for my family. Doing something with my phone is my 3rd priority at max (which is why I have neither posted on this list nor filed a bug report before), and sometimes I just want to use my phone. So, you see, in my eyes installing a package is trivial, and nobody should have to check how much memory a package consumes. I am perfectly capable of this situation, to be precise, I did so with PR1.1. I moved parts of /var/apt, /usr/share and even most locales to /home/user. But this is a time consuming process, time I would've liked to spend on other things. The same applies to removing apps before running an update. It's simply unnecessary. I mean, what you're telling the users is this: "Hey $user, we packaged a few cool apps that are even shown on youtube, and we would like you to use them. Give them a try, and if there's something wrong, file a bug report. Oh, well, but in case of an update, you're screwed. We expect you to handle this." This really sounds sensible... At the end of last year there was a hacker meeting taking place in germany. I showed my N900 to some of the people attending, some admired it, but others asked me why I use a phone "with a compiler". You see, there are even Nerds out there who do not want to tinker around with their devices. And most of them are very capable, providing code for Open Source projects, for example. They are capable - but they do not want to handle such a situation. And my eyes, they shouldn't have to. Because even the N900 is a tool, and as such, some stuff should "just work". Regards Christian Walther ___ maemo-users mailing list maemo-users@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-users
Re: Not enough memory
On Tue, Feb 16, 2010 at 22:15, Nelson Ferreira wrote: > I must say I am really disappointed at how painful it is to do an > update on the N900. > I went through this game on PR1.1 and now PR1.1.1. > > If Maemo or MeeGo want a shot at a good end-user consumer this really > should be up there in the priority for stuff to fix... > On Wed, Feb 17, 2010 at 18:01, Craig Woodward wrote: > > I swear I've never heard so much whining about a trivial topic in my life. > You'd think Nokia > was pushing a completely closed release from the yelping going on. You > installed 80 apps > from unstable or random repositories and sources, each time with a pop-up > from the OS > saying that what you're doing is unsupported and could cause device > instability. And now > you're complaining because an update is asking you to fix some of the damage > you've > done so it can do an upgrade? It's called being an adult. If you can't > handle it, stick to the > toys for 12 and under from now on. > > While I had no "problem" fixing it, it still took time to get around to do, and I believe that in an open source environment pointing out flaws and pain points is still valid. If that is not well seen in Maemo, then it will surely wither. I think that is not the case. You see, what for one is whining for others is making sure the real dimension of a problem is known. Again _I_ did not have a problem resolving it, but sure as well would have liked it to have been smoother. I also think most people having the issue are not installing from "random repositories" but rather are having problems from installs coming from a very specific repository: extras-devel, just because that is where the interesting stuff is brewing now. Once they move to extras I believe it will subside. However I do believe that the following suggestions should be considered by the team doing app manager: 1. Show from what repos the app/version is coming from. 2. Show the split between rootfs non rootfs requirements/usage, specially on uninstall 3. Allow for multiple selection for install/uninstall 4. Allow for the package cache to be out of rootfs ___ maemo-users mailing list maemo-users@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-users
Re: Not enough memory
Craig Woodward wrote: > I swear I've never heard so much whining about a trivial topic in my > life. You'd think Nokia was pushing a completely closed release from > the yelping going on. You installed 80 apps from unstable or random > repositories and sources, each time with a pop-up from the OS saying > that what you're doing is unsupported and could cause device > instability. And now you're complaining because an update is asking > you to fix some of the damage you've done so it can do an upgrade? > It's called being an adult. If you can't handle it, stick to the > toys for 12 and under from now on. > Amen. On a more technical, get-it-done approach, my problem with OOM was too much crap in /var/cache/apt/archive/ . There are two ways to handle this in a more user friendly manner. Instead of the OOM error message, offer to run 'apt-get clean', and/or symlink /var/cache/apt out to /home/.var.cache.apt . Which I just tried, and seems to wfm. $ sudo gainroot # cd /var/cache/ # mv apt /home/.var.cache.apt # ln -sf ../../home/.var.cache.apt apt # hth, Jason. ___ maemo-users mailing list maemo-users@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-users
Re: Not enough memory
Nelson Ferreira wrote: > On Wed, Feb 17, 2010 at 15:47, Jan Knutar wrote: >> On Wednesday 17 February 2010, Christian Walther wrote: >> >>> Apart from that, I really can't understand why Nokia doesn't supply >>> tools that allow to build clean packages, e.g. ones that install in a >>> location of their own, without saving *anything* to a location used >>> by the Maemo OS. >> All the developer has to do is create a debian/optify file in their >> project's sourcedir, with the contents "auto", and that works for the >> majority of cases. >> >>> And, honestly, what do you think is the appropriate reaction of any >>> user to a sentence like "The simple solution is to uninstall anything >>> not coming from "? Feels a bit like being slapped >>> in the face... >> There's a reason there's a warning about installing random crap from >> random place... Perhaps that warning should be made stronger... >> > > If only the App Manager would list the _source repository_ of the package... > >> Another nice feature would be if the application manager, or a web >> interface somewhere, could tell you beforehand how much space an app >> consumes on /... > > That too would be useful. Not as much as if the app manager didn't takes >10Mb of space for repo indexes -- "Don't worry, you'll be fine; I saw it work in a cartoon once..." ___ maemo-users mailing list maemo-users@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-users
Re: Not enough memory
Christian Walther wrote: >sorry, I have to agree with Johan -- it is crap. >A living and healthy ecosystem consists of ... consists of keep track of your own ecosystem usage. I don't take a crap on my dining room table, just like I don't install random software on my computer without watching what it does. I have tons of apps installed from various repositories, and was able to do the update OTA without any issues. How? Because when I installed apps I watched my "ecosystem" and hand-optified one or two packages that I liked and wanted to keep that took a lot of rootfs space. If you dump wherever you please, and don't watch where you're walking, you have little room to complain about stepping in your own mess later. >For the user it simply shouldn't matter where a package comes from, as >long as this package has been built using the official tools "and >stick to the rules" everything should be fine. They have that. It's called an iPhone. You can only install things built with the official tools that force everyone to "stick to the rules". I got an N900 because I don't like Apple's rules (namely I like to do more than 1 thing at a time). As for people screaming "the iPhone updates don't have this problem!", you are correct. They also don't offer major upgrades every other month. They also don't publicize how often people needed to take their phone in to iCare centers to get updated, which has happened a lot. The iPhone also doesn't let you install apps from wherever you please, or offer a free SDK package so you can make and install your own apps for free. There are a lot of things the iPhone doesn't let you do... and if you break the rules (jail breaking), updates are next to impossible. Recall how long it took for update 1 from iPhone to bring MMS to it? One year! For the N900 we had it in the devel repositories in under a month (kudos to frals). If you wanted an iPhone, you should have bought one. You don't shave with a bowling pin... buy the right tool for the right job. If you bought the wrong tool on impusle, please don't whine about it. Nokia and Maemo are known quantities, and a little research before the purchase (or before installing ioquake) would have told you this is not a computer for someone that don't know how to maintain a computer. As for having such a "tiny FS", my understanding is that was done because the first area of the flash is a different class (faster speed == more expensive) to enhance performance. There are discussion threads where people talk about having repartitioned their phone, or swapping rootfs and swap partitions around to have more rootfs at the cost of speed or less swap space. If you want to do that, YOU CAN. (Try that on an iPhone.) Reality is there are practical limitations on memory performance and cost. Nokia made a trade off to keep the production costs down, Maemo worked with that, and it's something that most people can live with. >Apart from that, I really can't understand why Nokia doesn't supply >tools that allow to build clean packages Most phone providers don't supply ANY SDK for their phones. Nokia at least provides something, and encourages others to create and distribute tools based on their designs. Can you imagine if a Debian virtual box image based on eclipse came out developing iPhone apps? They'd be off bumped off the net in hours, and sued into oblivion by Apple. Yet just such a download exists for the N900, and several other Nokia based phones. Maemo DOES have tools that optimize for the phone. It's a simple, well documented thing to turn optification on. The fact of the matter is that it can make debugging harder at times, so some developers don't enable it at first. For some major packages, (libraries, like python for example) it's a little more complex, especially for items not made specifically for the N900. Sometimes you have to branch off your own changes, and until you have time to do that, you want to get basic functionality working. I swear I've never heard so much whining about a trivial topic in my life. You'd think Nokia was pushing a completely closed release from the yelping going on. You installed 80 apps from unstable or random repositories and sources, each time with a pop-up from the OS saying that what you're doing is unsupported and could cause device instability. And now you're complaining because an update is asking you to fix some of the damage you've done so it can do an upgrade? It's called being an adult. If you can't handle it, stick to the toys for 12 and under from now on. ___ maemo-users mailing list maemo-users@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-users
Re: Not enough memory
On Wed, Feb 17, 2010 at 15:47, Jan Knutar wrote: > On Wednesday 17 February 2010, Christian Walther wrote: > >> Apart from that, I really can't understand why Nokia doesn't supply >> tools that allow to build clean packages, e.g. ones that install in a >> location of their own, without saving *anything* to a location used >> by the Maemo OS. > > All the developer has to do is create a debian/optify file in their > project's sourcedir, with the contents "auto", and that works for the > majority of cases. > >> And, honestly, what do you think is the appropriate reaction of any >> user to a sentence like "The simple solution is to uninstall anything >> not coming from "? Feels a bit like being slapped >> in the face... > > There's a reason there's a warning about installing random crap from > random place... Perhaps that warning should be made stronger... > If only the App Manager would list the _source repository_ of the package... > Another nice feature would be if the application manager, or a web > interface somewhere, could tell you beforehand how much space an app > consumes on /... That too would be useful. > ___ > 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: Not enough memory
On Wednesday 17 February 2010, Paul Hartman wrote: > I found that I had several themes, which were all optified, but still > take about 500k each on rootfs... After uninstalling all themes > (leaving the 2 built-in) I then had enough space to install the > update... Also for many people just disabling extras-testing and extras-devel if they have them enabled in Application Manager has freed up enough space. Having them enabled seems to consume vast amounts of space. ___ maemo-users mailing list maemo-users@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-users
Re: Not enough memory
On Wednesday 17 February 2010, Christian Walther wrote: > Apart from that, I really can't understand why Nokia doesn't supply > tools that allow to build clean packages, e.g. ones that install in a > location of their own, without saving *anything* to a location used > by the Maemo OS. All the developer has to do is create a debian/optify file in their project's sourcedir, with the contents "auto", and that works for the majority of cases. > And, honestly, what do you think is the appropriate reaction of any > user to a sentence like "The simple solution is to uninstall anything > not coming from "? Feels a bit like being slapped > in the face... There's a reason there's a warning about installing random crap from random place... Perhaps that warning should be made stronger... Another nice feature would be if the application manager, or a web interface somewhere, could tell you beforehand how much space an app consumes on /... ___ maemo-users mailing list maemo-users@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-users
Re: Not enough memory
On Wed, Feb 17, 2010 at 10:55 AM, Johan Helsingius wrote: > Daniel Martin Yerga wrote: > >> That's not crap, it's a very wise advise. >> If you want that everything works as it should, then only use > stable software from Extras and Ovi. You will able to update without > problems. > > Sorry, but no. I am only using stable software from Ovi and Extras. > It still didn't work. > > And blaming your users for your mistake of incorrectly > partitioning the flash memory is not very wise advise. I found that I had several themes, which were all optified, but still take about 500k each on rootfs... After uninstalling all themes (leaving the 2 built-in) I then had enough space to install the update... N900 with bigger rootfs and more RAM would be great ;) Maybe the next one... ___ maemo-users mailing list maemo-users@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-users
Re: Not enough memory
Daniel Martin Yerga wrote: > That's not crap, it's a very wise advise. > If you want that everything works as it should, then only use stable software from Extras and Ovi. You will able to update without problems. Sorry, but no. I am only using stable software from Ovi and Extras. It still didn't work. And blaming your users for your mistake of incorrectly partitioning the flash memory is not very wise advise. Julf ___ maemo-users mailing list maemo-users@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-users
Re: Not enough memory
Hi, On 17 February 2010 09:49, Daniel Martin Yerga wrote: > Hi. > > - Original message - >> Nelson, >> >> > I must say I am really disappointed at how painful it is to do an >> > update on the N900. >> >> I have to agree. I was especially annoyed by the crap on >> http://wiki.maemo.org/Maemo_5/PR1.1.1: >> >> "There are reports that at least 42MB of free rootfs is needed for >> the update. You have probably installed unstable software from >> Extras-devel or other source with weak quality control. The simple >> solution is to uninstall anything not coming from Ovi and maemo.org >> Extras." > > That's not crap, it's a very wise advise. > If you want that everything works as it should, then only use stable software > from Extras and Ovi. You will able to update without problems. sorry, I have to agree with Johan -- it is crap. A living and healthy ecosystem consists of applications that attract users. Not all of these applications are good, it's mainly about quantity (which gives the user a choice). This is one argument for the iPhone (90.000 apps in the store). So basically Extras and Ovi is not enough. I don't know about you, but most news I read were about either the iPhone or Android. That's the hype. Nokia recently either has no media coverage, or a rather bad one. Yesterday for example I heard a newsman saying that "until two years ago, there were no Apps and that people had to stick to applications installed by their carrier." Obviously these people missed ages of Symbian smartphones that allowed to install apps downloaded from the internet. The merger of Maemo and Moblin to MeeGO? Many people consider this to be a bad thing, because of all the changes Nokia made to its smartphone ecosystem recently. There's the Qt vs. Gtk issue (is there a need to port all apps to Qt? Will Gtk be dropped?), which is discussed in comments of german news articles. Maemo 6 goes along the same lines: Why publish a new major version number of an OS, when its predecessor is not even a year old, and still has bugs? Some people wonder if buying a N900 is a good thing, because the question really is if Maemo 6 will run on it. Nobody wants to waste 600 Euro on a device that is deprecated a few month later.. The "Ovi maps 3.0" issue has been discussed on this list, too. Yes, it matters to the end user. Why pick Maemo when the apps for Symbian are much more advanced and mature? Nokia should've released Ovi maps 3.0 for Maemo, too, because it would've shown that they are committing to Maemo. Bottom line: Maemo isn't an established smartphone OS and all the changes recently made don't work in this direction. Apart from that, I really can't understand why Nokia doesn't supply tools that allow to build clean packages, e.g. ones that install in a location of their own, without saving *anything* to a location used by the Maemo OS. This is not impossible, on the contrary: All BSDs have a packaging and build system that does exactly this, same applies to OpenCSW for Solaris packages. Both even install newer libraries if needed... The space issue reminds me of days long ago and nearly forgotten: When I first got my Sharp Zaurus SL-5000 it was a problem to install additional software, and several attempts were made to solve this. That this issue exists in 2010, in the 5th release of an OS makes me wonder what Nokia before. And yes, I know that this is maemo.org and that it isn't driven by Nokia. But IMO Maemo can be considered as being a Open Source project, and as such it is about a community, consisting of active developers and users. And developers AFAIK want powerful tools. It should be in Nokias best interest to cater for its community. Please don't get me wrong, I really like Maemo and had many reasons to choose the N900 about any other device. I don't regret the choice but think that we should openly discuss Maemo flaws. One of Maemos strengths is its openness, which should be of interest for any open source enthusiast. It doesn't rely on an appstore, and its packages are available freely on the net in a well known format. This is simply brilliant and a dream coming true! OpenVPN, an Instant Messenger that can be installed using plugins (or Pidgin), the possibility to use any programming language one wants, a vast amount of media players supporting many different formats -- just to name a few. For the user it simply shouldn't matter where a package comes from, as long as this package has been built using the official tools "and stick to the rules" everything should be fine. AFAIK "maemo-optify" is a community solution, but it should've been supplied by Nokia in the first place. And, honestly, what do you think is the appropriate reaction of any user to a sentence like "The simple solution is to uninstall anything not coming from "? Feels a bit like being slapped in the face... Regards Christian Walther ___ maemo-users mailing list maemo-users@maemo.org https://lists.ma
Re: Not enough memory
On Wednesday 17 February 2010 00:40:28 Kahlil Johnson wrote: > Hi I just got a maemo release on 16mb of update but when I want to > install it says not enough memory, is there any notes with the update. > I have 1.6GB of memory and 17 on the user space and a 16GB card > available completely. I guess it has to do with some root directory > but I wonder where to get the installation notes. I found that an "apt-get clean" is often enough. Bye, -- Daniele "Vihai" Orlandi Bieco Illuminista #184213 ___ maemo-users mailing list maemo-users@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-users
Re: Not enough memory
Hi. - Original message - > Nelson, > > > I must say I am really disappointed at how painful it is to do an > > update on the N900. > > I have to agree. I was especially annoyed by the crap on > http://wiki.maemo.org/Maemo_5/PR1.1.1: > > "There are reports that at least 42MB of free rootfs is needed for > the update. You have probably installed unstable software from > Extras-devel or other source with weak quality control. The simple > solution is to uninstall anything not coming from Ovi and maemo.org > Extras." That's not crap, it's a very wise advise. If you want that everything works as it should, then only use stable software from Extras and Ovi. You will able to update without problems. ___ maemo-users mailing list maemo-users@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-users
Re: Not enough memory
Nelson, > I must say I am really disappointed at how painful it is to do an > update on the N900. I have to agree. I was especially annoyed by the crap on http://wiki.maemo.org/Maemo_5/PR1.1.1: "There are reports that at least 42MB of free rootfs is needed for the update. You have probably installed unstable software from Extras-devel or other source with weak quality control. The simple solution is to uninstall anything not coming from Ovi and maemo.org Extras." Julf ___ maemo-users mailing list maemo-users@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-users
Re: Not enough memory
I must say I am really disappointed at how painful it is to do an update on the N900. I went through this game on PR1.1 and now PR1.1.1. If Maemo or MeeGo want a shot at a good end-user consumer this really should be up there in the priority for stuff to fix... Just my 2c On Tue, Feb 16, 2010 at 21:00, Tim Ashman wrote: > On Tuesday 16 February 2010 03:43:10 pm Andre Klapper wrote: >> Am Dienstag, den 16.02.2010, 17:40 -0600 schrieb Kahlil Johnson: >> > Hi I just got a maemo release on 16mb of update but when I want to >> > install it says not enough memory, is there any notes with the update. >> > I have 1.6GB of memory and 17 on the user space and a 16GB card >> > available completely. I guess it has to do with some root directory >> > but I wonder where to get the installation notes. >> >> Please see the "Not enough space?" section in >> http://wiki.maemo.org/Maemo_5/PR1.1.1 >> >> andre > > I ended up using the flasher and just flashing the whole device. Just backup > first and the then restore when you are done and everything will be as it > was. Make sure your backup is on the external card! > > tim > > ___ > 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: Not enough memory
On Tuesday 16 February 2010 03:43:10 pm Andre Klapper wrote: > Am Dienstag, den 16.02.2010, 17:40 -0600 schrieb Kahlil Johnson: > > Hi I just got a maemo release on 16mb of update but when I want to > > install it says not enough memory, is there any notes with the update. > > I have 1.6GB of memory and 17 on the user space and a 16GB card > > available completely. I guess it has to do with some root directory > > but I wonder where to get the installation notes. > > Please see the "Not enough space?" section in > http://wiki.maemo.org/Maemo_5/PR1.1.1 > > andre I ended up using the flasher and just flashing the whole device. Just backup first and the then restore when you are done and everything will be as it was. Make sure your backup is on the external card! tim ___ maemo-users mailing list maemo-users@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-users
Re: Not enough memory
Am Dienstag, den 16.02.2010, 17:40 -0600 schrieb Kahlil Johnson: > Hi I just got a maemo release on 16mb of update but when I want to > install it says not enough memory, is there any notes with the update. > I have 1.6GB of memory and 17 on the user space and a 16GB card > available completely. I guess it has to do with some root directory > but I wonder where to get the installation notes. Please see the "Not enough space?" section in http://wiki.maemo.org/Maemo_5/PR1.1.1 andre -- Andre Klapper (maemo.org bugmaster) ___ maemo-users mailing list maemo-users@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-users
Not enough memory
Hi I just got a maemo release on 16mb of update but when I want to install it says not enough memory, is there any notes with the update. I have 1.6GB of memory and 17 on the user space and a 16GB card available completely. I guess it has to do with some root directory but I wonder where to get the installation notes. -- Kahlil Johnson "Ya tengo GMAIL!!" ___ maemo-users mailing list maemo-users@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-users
RE: [maemo-users] Re: Not enough memory to show a PDF file
Hi, Would you file a bug report (and perhaps attach the smallest file that does not render): https://maemo.org/bugzilla/ Other interested people could then CC themselves to it and check the progress. Thanks! --jakub >From: [EMAIL PROTECTED] >I too am experiencing similar problems. There were several >PDFs that would routinely open under the 2005 OS, most of >which were under 1 MB. However, they will not open in the PDF >Viewer under OS2006. What is strange is that most of these >files are simply plain text, however, magazine articles with >text and pictures (about three times the size in memory) open >and operate just fine. <8-\ > >I have tried extending virtual memory up to 24 MB (and even >restarted) with no difference. What gives? > >J. > >> Message: 3 >> Date: Mon, 03 Jul 2006 16:44:39 +0300 >> From: Ville Ranki <[EMAIL PROTECTED]> >> Subject: Re: [maemo-users] Not enough memory to show a PDF file >> To: maemo-users@maemo.org >> Message-ID: <[EMAIL PROTECTED]> >> Content-Type: text/plain >> >> On Sat, 2006-07-01 at 00:16 -0700, Israel Herraiz wrote: >> >>> Hi, >>> >>> I have just installed the last version of the 2006 OS, and I am >>> experiencing a strange bug with the PDF reader. >>> >>> I could see this file [1] perfectly with the beta version, but now >>> with the final version it claims "Not enough memory to show page" >>> every time the shown page has an image. >>> >> >> I can confirm this bug - i have a 42MB PDF that used to load >on 2005. >> Now it complains out of memory every time i try to open it. I have >> swap enabled. >> >> -- >> -- Ville Ranki oh3gbq >>[EMAIL PROTECTED] 040-757 2533 >>http://www.iki.fi/~cos/ >___ >maemo-users mailing list >maemo-users@maemo.org >https://maemo.org/mailman/listinfo/maemo-users > ___ maemo-users mailing list maemo-users@maemo.org https://maemo.org/mailman/listinfo/maemo-users
[maemo-users] Re: Not enough memory to show a PDF file
I too am experiencing similar problems. There were several PDFs that would routinely open under the 2005 OS, most of which were under 1 MB. However, they will not open in the PDF Viewer under OS2006. What is strange is that most of these files are simply plain text, however, magazine articles with text and pictures (about three times the size in memory) open and operate just fine. <8-\ I have tried extending virtual memory up to 24 MB (and even restarted) with no difference. What gives? J. Message: 3 Date: Mon, 03 Jul 2006 16:44:39 +0300 From: Ville Ranki <[EMAIL PROTECTED]> Subject: Re: [maemo-users] Not enough memory to show a PDF file To: maemo-users@maemo.org Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain On Sat, 2006-07-01 at 00:16 -0700, Israel Herraiz wrote: Hi, I have just installed the last version of the 2006 OS, and I am experiencing a strange bug with the PDF reader. I could see this file [1] perfectly with the beta version, but now with the final version it claims "Not enough memory to show page" every time the shown page has an image. I can confirm this bug - i have a 42MB PDF that used to load on 2005. Now it complains out of memory every time i try to open it. I have swap enabled. -- -- Ville Ranki oh3gbq [EMAIL PROTECTED] 040-757 2533 http://www.iki.fi/~cos/ ___ maemo-users mailing list maemo-users@maemo.org https://maemo.org/mailman/listinfo/maemo-users
Re: [maemo-users] Not enough memory to show a PDF file
[EMAIL PROTECTED] wrote: > What you could do is to enable swap on MMC and try again. > If it works with the swap enabled, for some reason you are entering > in low memory situation sooner now than before. Did you test it > with no other programs running? I have 64 MB of swap, set up using the Control Panel. I have tried it only with the PDF reader open. > However, if the problem doesn't go away even with swap enabled, > it might be a bug.. It might be :-). BR, Israel -- Israel Herraiz | Libre Software Engineering Lab (GSyC) [EMAIL PROTECTED] | Universidad Rey Juan Carlos http://libresoft.urjc.es | Edif. Departamental II - Despacho 118 Telf: (+34) 91 488 8523| c/Tulipán s/n 28933 Móstoles (Madrid) ___ maemo-users mailing list maemo-users@maemo.org https://maemo.org/mailman/listinfo/maemo-users
Re: [maemo-users] Not enough memory to show a PDF file
On Sat, 2006-07-01 at 00:16 -0700, Israel Herraiz wrote: > Hi, > > I have just installed the last version of the 2006 OS, and I am > experiencing a strange bug with the PDF reader. > > I could see this file [1] perfectly with the beta version, but now with > the final version it claims "Not enough memory to show page" every time > the shown page has an image. I can confirm this bug - i have a 42MB PDF that used to load on 2005. Now it complains out of memory every time i try to open it. I have swap enabled. -- -- Ville Ranki oh3gbq [EMAIL PROTECTED] 040-757 2533 http://www.iki.fi/~cos/ ___ maemo-users mailing list maemo-users@maemo.org https://maemo.org/mailman/listinfo/maemo-users
RE: [maemo-users] Not enough memory to show a PDF file
Hello, What you could do is to enable swap on MMC and try again. If it works with the swap enabled, for some reason you are entering in low memory situation sooner now than before. Did you test it with no other programs running? However, if the problem doesn't go away even with swap enabled, it might be a bug.. Br, Karoliina >-Original Message- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] On Behalf Of ext Israel Herraiz >Sent: 01 July, 2006 10:18 >To: maemo-users@maemo.org >Subject: Re: [maemo-users] Not enough memory to show a PDF file > >By the way, I can provide the PDF file under request for >testing purposes (it is not available if you don't have a IEEE >account). > >-- >Israel Herraiz | Libre Software Engineering Lab (GSyC) >[EMAIL PROTECTED] | Universidad Rey Juan Carlos >http://libresoft.urjc.es | Edif. Departamental II - Despacho 118 >Telf: (+34) 91 488 8523| c/Tulipán s/n 28933 Móstoles (Madrid) > >___ >maemo-users mailing list >maemo-users@maemo.org >https://maemo.org/mailman/listinfo/maemo-users > ___ maemo-users mailing list maemo-users@maemo.org https://maemo.org/mailman/listinfo/maemo-users
Re: [maemo-users] Not enough memory to show a PDF file
By the way, I can provide the PDF file under request for testing purposes (it is not available if you don't have a IEEE account). -- Israel Herraiz | Libre Software Engineering Lab (GSyC) [EMAIL PROTECTED] | Universidad Rey Juan Carlos http://libresoft.urjc.es | Edif. Departamental II - Despacho 118 Telf: (+34) 91 488 8523| c/Tulipán s/n 28933 Móstoles (Madrid) ___ maemo-users mailing list maemo-users@maemo.org https://maemo.org/mailman/listinfo/maemo-users
[maemo-users] Not enough memory to show a PDF file
Hi, I have just installed the last version of the 2006 OS, and I am experiencing a strange bug with the PDF reader. I could see this file [1] perfectly with the beta version, but now with the final version it claims "Not enough memory to show page" every time the shown page has an image. It does not happen with other files with images, so I don't know if it is a real big bug (maybe it is just an issue with this specific file [1]). Anyhow, it would be great if someone else could check if this happens with PDF files which were shown correctly with the beta version, but can not be fully shown with this new version. BR, Israel [1] http://ieeexplore.ieee.org/iel5/32/34428/01642679.pdf?isnumber=34428&prod=JNL&arnumber=1642679&arSt=+315&ared=+329&arAuthor=+Kelly%2C+D. -- Israel Herraiz | Libre Software Engineering Lab (GSyC) [EMAIL PROTECTED] | Universidad Rey Juan Carlos http://libresoft.urjc.es | Edif. Departamental II - Despacho 118 Telf: (+34) 91 488 8523| c/Tulipán s/n 28933 Móstoles (Madrid) ___ maemo-users mailing list maemo-users@maemo.org https://maemo.org/mailman/listinfo/maemo-users
