Opt Problem - Revision history

178.165.183.141: fix typo

2010-06-03T14:38:26Z

fix typo

← Older revision		Revision as of 14:38, 3 June 2010
Line 36:		Line 36:

	= Tool for detection of non-optified packages =		= Tool for detection of non-optified packages =
	[[Image:Storageusage.png\|thumb\|300px\|<br>[http://code.google.com/p/storageusage/ Storage ~~Useage~~] provides a great visual way to detect non-optified packages.		[[Image:Storageusage.png\|thumb\|300px\|<br>[http://code.google.com/p/storageusage/ Storage Usage] provides a great visual way to detect non-optified packages.
	]]		]]

imported_>jeffburdges: /* Chroot install in /opt, symlink to where it belongs */

2010-04-26T12:11:49Z

Chroot install in /opt, symlink to where it belongs

← Older revision		Revision as of 12:11, 26 April 2010
Line 125:		Line 125:
	* Maybe somebody can see something good in this?		* Maybe somebody can see something good in this?
	* Difficult hack.. would need all the tools etc to be visible in the chroot.		* Difficult hack.. would need all the tools etc to be visible in the chroot.

			==== Make /usr another partition ====
			You know, historically /usr exists entirely for the purpose of separating the application partition from the underlying system, which is exactly our problem.
			* All the core nokia software and libraries should be relocated to / or maybe a /maemo.
			* /usr and /opt should become symlinks to /home/usr and /home/opt.
			* Maemo targeted GUI software would be encouraged to use /opt/[application].
			* Linux libraries and CLI software could safely use /usr, minimizing the required modifications.
			* Any frequently used accessed files in /home but not /home/user/MyDocs could be cached in /cache, which then gets overlaid with /home using unionfs or something more specialized.
			* Another location like /alt could be used by packages that know they need the NAND's speed, but this is discouraged.

	[[Category:Development]]		[[Category:Development]]

imported_>amigadave: /* The /opt Problem */ link to rootfs

2010-03-03T16:09:29Z

The /opt Problem: link to rootfs

← Older revision		Revision as of 16:09, 3 March 2010
Line 1:		Line 1:
	= The /opt Problem =		= The /opt Problem =

	There is not enough space on ~~root~~ to fit all applications, therefore additional partition has to be used. But ~~just~~ how?		There is not enough space on the [[rootfs]] to fit all applications, therefore an additional partition has to be used. But how?

	There is a section in the Maemo 5 Developer Guide explaining the basics:		There is a section in the Maemo 5 Developer Guide explaining the basics:

imported_>jukey: /* Some goals */

2010-02-25T10:53:14Z

Some goals

← Older revision		Revision as of 10:53, 25 February 2010
Line 25:		Line 25:
	* A fix should be doable after shipping (before shipping, probably not?)		* A fix should be doable after shipping (before shipping, probably not?)

	== Current problems / developer and packaging issues ==		= Current problems / developer and packaging issues =

	This should be a list of current problems developers are experiencing related to optification:		This should be a list of current problems developers are experiencing related to optification:
Line 35:		Line 35:
	* [[/Non-Optified_packages\|List of non-optified packages and applications]] - Please feel free to add every piece of software which is using too much space in rootfs		* [[/Non-Optified_packages\|List of non-optified packages and applications]] - Please feel free to add every piece of software which is using too much space in rootfs

	== Tool for detection of non-optified packages ==		= Tool for detection of non-optified packages =
	[[Image:Storageusage.png\|thumb\|300px\|<br>[http://code.google.com/p/storageusage/ Storage Useage] provides a great visual way to detect non-optified packages.		[[Image:Storageusage.png\|thumb\|300px\|<br>[http://code.google.com/p/storageusage/ Storage Useage] provides a great visual way to detect non-optified packages.
	]]		]]

imported_>jukey: /* Current problems / developer and packaging issues */

2010-02-25T10:49:36Z

Current problems / developer and packaging issues

← Older revision		Revision as of 10:49, 25 February 2010
Line 34:		Line 34:

	* [[/Non-Optified_packages\|List of non-optified packages and applications]] - Please feel free to add every piece of software which is using too much space in rootfs		* [[/Non-Optified_packages\|List of non-optified packages and applications]] - Please feel free to add every piece of software which is using too much space in rootfs

			== Tool for detection of non-optified packages ==
			[[Image:Storageusage.png\|thumb\|300px\|<br>[http://code.google.com/p/storageusage/ Storage Useage] provides a great visual way to detect non-optified packages.
			]]

	= Possible solutions, even the bad ones =		= Possible solutions, even the bad ones =

imported_>amigadave: /* The /opt Problem */ wikify link

2010-02-22T08:35:45Z

The /opt Problem: wikify link

← Older revision		Revision as of 08:35, 22 February 2010
Line 4:		Line 4:

	There is a section in the Maemo 5 Developer Guide explaining the basics:		There is a section in the Maemo 5 Developer Guide explaining the basics:
	[~~http://wiki.maemo.org/~~Documentation/Maemo_5_Developer_Guide/Packaging~~%2C_Deploying_and_Distributing~~/Installing_under_opt_and_MyDocs Installing under /opt and /MyDocs]		[[Documentation/Maemo_5_Developer_Guide/Packaging,_Deploying_and_Distributing/Installing_under_opt_and_MyDocs\|Installing under /opt and /MyDocs]]

	= Current situation =		= Current situation =

imported_>torpedo48: /* The /opt Problem */

2010-02-21T18:12:52Z

The /opt Problem

← Older revision		Revision as of 18:12, 21 February 2010
Line 3:		Line 3:
	There is not enough space on root to fit all applications, therefore additional partition has to be used. But just how?		There is not enough space on root to fit all applications, therefore additional partition has to be used. But just how?

	There is a section in the Maemo 5 Developer Guide explaining the basics:		There is a section in the Maemo 5 Developer Guide explaining the basics:
	http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/Packaging%2C_Deploying_and_Distributing/Installing_under_opt_and_MyDocs		[http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/Packaging%2C_Deploying_and_Distributing/Installing_under_opt_and_MyDocs Installing under /opt and /MyDocs]

	= Current situation =		= Current situation =

imported_>tanner: use opt/maemo

2010-02-02T07:38:53Z

use opt/maemo

← Older revision		Revision as of 07:38, 2 February 2010
Line 50:		Line 50:
	==== Have a 2-5gb partition on the emmc for addon packages mounted to /usr/local or /opt ====		==== Have a 2-5gb partition on the emmc for addon packages mounted to /usr/local or /opt ====
	* Most apps by default usually go there		* Most apps by default usually go there
	* for /opt store according to the FHS standard /opt/<package> and symlink to /opt/{bin,lib,share,...} actually the standard is /opt/<vendor>/whatever In this case using /opt/maemo directly would work.		* for /opt store according to the FHS standard /opt/<package> and symlink to /opt/maemo/{bin,lib,share,...} (actually the standard is /opt/<vendor>/whatever In this case using /opt/maemo directly would work).
	* Having ld.so.conf and PATH set properly avoids all the symlink madness		* Having ld.so.conf and PATH set properly avoids all the symlink madness
	* Don't do symlinks for /usr/local\|/opt - make it a real partition		* Don't do symlinks for /usr/local\|/opt - make it a real partition

imported_>tanner: link to my more elaborated solution

2010-02-02T07:37:38Z

link to my more elaborated solution

← Older revision		Revision as of 07:37, 2 February 2010
Line 58:		Line 58:

	==== store addon packages completely in /home/opt hierarchy ====		==== store addon packages completely in /home/opt hierarchy ====
			* [http://wiki.maemo.org/User:Tanner#full_optification see this page]
	* like previous solution but on the standard /home partition		* like previous solution but on the standard /home partition
	* very clean solution ~~if speed advantage of OneNAND over eMMC turns out to~~ be ~~a myth~~		* very clean solution as no files (except for /var/lib/dpkg which may be moved as well) are created or modified on the NAND.
	* /etc and /var could be copied there as well and mounted to root using bind. This way OneNAND would only be changed be reflashes and if /home is not mounted (e.g., by a keypress during boot) a fallback system could boot from unmodified OneNAND.		* /etc and /var could be copied there as well and mounted to root using bind. This way OneNAND would only be changed be reflashes and if /home is not mounted (e.g., by a keypress during boot) a fallback system could boot from unmodified OneNAND.
	* if OneNAND is significantly faster, mark some often used shared libraries as candidates for a /usr/lib/cache directory in which they are copied during installation until a certain cache limit is reached.		* if OneNAND is significantly faster, mark some often used shared libraries as candidates for a /usr/lib/cache directory in which they are copied during installation until a certain cache limit is reached.

imported_>tanner: add benchmarks results

2010-01-31T22:40:23Z

add benchmarks results

← Older revision		Revision as of 22:40, 31 January 2010
Line 12:		Line 12:
	* symlink: /opt/ -> /home/opt/		* symlink: /opt/ -> /home/opt/
	* OneNAND is probably "much" faster than the eMMC (hard numbers? read? write? small blobs? big blobs?)		* OneNAND is probably "much" faster than the eMMC (hard numbers? read? write? small blobs? big blobs?)
			* file system [http://talk.maemo.org/showpost.php?p=504332&postcount=76 benchmark results] for different media
	* OneNAND performance figures: Sustained read performance: 108MB/s. Sustained write performance: up to 17MB/s. See [http://www.samsung.com/global/business/semiconductor/products/fusionmemory/downloads/onenand_brochure_200609.pdf Samsung OneNAND specs].		* OneNAND performance figures: Sustained read performance: 108MB/s. Sustained write performance: up to 17MB/s. See [http://www.samsung.com/global/business/semiconductor/products/fusionmemory/downloads/onenand_brochure_200609.pdf Samsung OneNAND specs].
	* eMMC performance figures: read performance 37MB/s. Write performance 20MB/s. Write speed of 17MB/s has been achieved in this test at [http://symbianbriefs.blogspot.com/2010/01/n900-review-part-10-transferring-data.html symbianbriefs.blogspot.com]. My own read tests however show ~11MB/s (370MB file).		* eMMC performance figures: read performance 37MB/s. Write performance 20MB/s. Write speed of 17MB/s has been achieved in this test at [http://symbianbriefs.blogspot.com/2010/01/n900-review-part-10-transferring-data.html symbianbriefs.blogspot.com]. My own read tests however show ~11MB/s (370MB file).