Re: Autorun for SD card mechanism?
Lothar Behrens wrote: Yes, I agree with that when data should be used from sdcard, if there are these files. That would be the quick hack in my mind. But I brought up my points in case if there are applications for specific distros and versions that may be incompatible to each other? I don't know if the issue will make the whole thing too complex, but I thought to discuss about it. I have had a case where I gone back to an older version, but it didn't worked any more and I didn't know, wich versions do fit together. risk of the user ;) I would only install packages with stuff like fonts, keyboards etc. and only if they are not available in the default repositories. let's keep it simple. Am 09.04.2009 um 01:02 schrieb Pander: A directory called /media/card/post/linked with e.g. files like /media/card/post/linked/root/.cellhunter /media/card/post/linked/root/Maps/ the original /root/.cellhunter file and /root/Maps directory will be deleted and a soft link will be created to the ones in linked directory. Lothar Behrens wrote: Ok, as the idea was good, more thoughts: 1.) Using the sd card to store jet installed application information is not good. Then it would only run the first distro switch. 2.) Keep in mind, that packages from the usual opkg may be installed in later releases. And it may or may not reinstalled. 3.) Using a database repository in the net to update a local database of applications that may installable without problems per distro. 4.) If a user add's an application with opkg, a choice could be made to activate autoinstall for later switches. 5.) If the application isn't in the database on the net, or the local copy, add it but mark it as untested. 6.) The database could be used for a hitlist of installed applications that would really used, because a reinstall could be counted. 7.) Untested applications that should be installed, could be complained about and a choice could be made. 8.) Feedback if successfully installed application makes problems. The user should be asked some time later and he/she may make choices as of like this: 'App1 is usable', 'App2 has problems on this distro' and so forth. That way, we get feedback of the most used applications, we see the quality in the installability and we may spot conflicts. Next, if a distro decides to add an application as default, it could be marked as installed by that distro. This leads propably to an update process per distro and thus a local copy (if there will be really some for offline installations) could either removed any time - by asking or the app on the card could also get updated. Keep in mind that there are issues with the applications data. If this data is not at least backed up to sd card, a distro switch may kill your data :-) Also keep in mind, that users don't want to give that feedback. We don't do it like some companies do collect their statistical :-) It is not easy and I don't like to only create a quick hack, that would not work at all. Lothar Am 08.04.2009 um 16:28 schrieb Pander: in the first boot, also make the most default choices of all when /media/card/post directory is found. e.g. English, Illume SHR theme, ..., next, next, next, finish ;) Johny Tenfinger wrote: Hmm... Maybe there is a place for some app... shr-firstboot :) It could also replace first boot creator from e17, which isn't very useful on Neos... 2009/4/8, Pander pan...@users.sourceforge.net: good idea. I already have all those files on SD but after each upgrade have to install them manually, which is annoying. I would suggest something like: 1) notify user to do an opkg update and opkg upgrade first 2) change to post installation directory cd /media/card/post 3) change to package directory and install all that is in there cd packages opkg install *.ipk *.opk cd .. 4) override files cd override [[copy all files to root of system, e.g. override/etc/blabla to /etc/blabla]] cd .. 5) path files cd patches [[apply all patchers to root of system]] cd .. off course documenting your changes via patches/diffs is preferred over overriding, allowing improvements in other parts of the files via opkg upgrade before you start. Johny Tenfinger wrote: Shortly: Let's write it ;) 2009/4/8, Lothar Behrens lothar.behr...@lollisoft.de: There is an idea rattling in my head about the following issue: Given I have a micro SD card and that would have all here, what is about a bootstrap mechanism to post install packages that are laying on that card to be installed, when a new image is started at first time? Like the autorun of a CD, this would help to ease the distro switch but keep my usual applications that otherwise have to be installed manually. This would include SSH settings, WLAN settings, look and feel, and what ever may possible. What about it? -- | Rapid Prototyping | XSLT Codegeneration
Autorun for SD card mechanism?
There is an idea rattling in my head about the following issue: Given I have a micro SD card and that would have all here, what is about a bootstrap mechanism to post install packages that are laying on that card to be installed, when a new image is started at first time? Like the autorun of a CD, this would help to ease the distro switch but keep my usual applications that otherwise have to be installed manually. This would include SSH settings, WLAN settings, look and feel, and what ever may possible. What about it? -- | Rapid Prototyping | XSLT Codegeneration | http://www.lollisoft.de Lothar Behrens Heinrich-Scheufelen-Platz 2 73252 Lenningen ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Autorun for SD card mechanism?
Shortly: Let's write it ;) 2009/4/8, Lothar Behrens lothar.behr...@lollisoft.de: There is an idea rattling in my head about the following issue: Given I have a micro SD card and that would have all here, what is about a bootstrap mechanism to post install packages that are laying on that card to be installed, when a new image is started at first time? Like the autorun of a CD, this would help to ease the distro switch but keep my usual applications that otherwise have to be installed manually. This would include SSH settings, WLAN settings, look and feel, and what ever may possible. What about it? -- | Rapid Prototyping | XSLT Codegeneration | http://www.lollisoft.de Lothar Behrens Heinrich-Scheufelen-Platz 2 73252 Lenningen ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Autorun for SD card mechanism?
good idea. I already have all those files on SD but after each upgrade have to install them manually, which is annoying. I would suggest something like: 1) notify user to do an opkg update and opkg upgrade first 2) change to post installation directory cd /media/card/post 3) change to package directory and install all that is in there cd packages opkg install *.ipk *.opk cd .. 4) override files cd override [[copy all files to root of system, e.g. override/etc/blabla to /etc/blabla]] cd .. 5) path files cd patches [[apply all patchers to root of system]] cd .. off course documenting your changes via patches/diffs is preferred over overriding, allowing improvements in other parts of the files via opkg upgrade before you start. Johny Tenfinger wrote: Shortly: Let's write it ;) 2009/4/8, Lothar Behrens lothar.behr...@lollisoft.de: There is an idea rattling in my head about the following issue: Given I have a micro SD card and that would have all here, what is about a bootstrap mechanism to post install packages that are laying on that card to be installed, when a new image is started at first time? Like the autorun of a CD, this would help to ease the distro switch but keep my usual applications that otherwise have to be installed manually. This would include SSH settings, WLAN settings, look and feel, and what ever may possible. What about it? -- | Rapid Prototyping | XSLT Codegeneration | http://www.lollisoft.de Lothar Behrens Heinrich-Scheufelen-Platz 2 73252 Lenningen ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Autorun for SD card mechanism?
Hmm... Maybe there is a place for some app... shr-firstboot :) It could also replace first boot creator from e17, which isn't very useful on Neos... 2009/4/8, Pander pan...@users.sourceforge.net: good idea. I already have all those files on SD but after each upgrade have to install them manually, which is annoying. I would suggest something like: 1) notify user to do an opkg update and opkg upgrade first 2) change to post installation directory cd /media/card/post 3) change to package directory and install all that is in there cd packages opkg install *.ipk *.opk cd .. 4) override files cd override [[copy all files to root of system, e.g. override/etc/blabla to /etc/blabla]] cd .. 5) path files cd patches [[apply all patchers to root of system]] cd .. off course documenting your changes via patches/diffs is preferred over overriding, allowing improvements in other parts of the files via opkg upgrade before you start. Johny Tenfinger wrote: Shortly: Let's write it ;) 2009/4/8, Lothar Behrens lothar.behr...@lollisoft.de: There is an idea rattling in my head about the following issue: Given I have a micro SD card and that would have all here, what is about a bootstrap mechanism to post install packages that are laying on that card to be installed, when a new image is started at first time? Like the autorun of a CD, this would help to ease the distro switch but keep my usual applications that otherwise have to be installed manually. This would include SSH settings, WLAN settings, look and feel, and what ever may possible. What about it? -- | Rapid Prototyping | XSLT Codegeneration | http://www.lollisoft.de Lothar Behrens Heinrich-Scheufelen-Platz 2 73252 Lenningen ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Autorun for SD card mechanism?
in the first boot, also make the most default choices of all when /media/card/post directory is found. e.g. English, Illume SHR theme, ..., next, next, next, finish ;) Johny Tenfinger wrote: Hmm... Maybe there is a place for some app... shr-firstboot :) It could also replace first boot creator from e17, which isn't very useful on Neos... 2009/4/8, Pander pan...@users.sourceforge.net: good idea. I already have all those files on SD but after each upgrade have to install them manually, which is annoying. I would suggest something like: 1) notify user to do an opkg update and opkg upgrade first 2) change to post installation directory cd /media/card/post 3) change to package directory and install all that is in there cd packages opkg install *.ipk *.opk cd .. 4) override files cd override [[copy all files to root of system, e.g. override/etc/blabla to /etc/blabla]] cd .. 5) path files cd patches [[apply all patchers to root of system]] cd .. off course documenting your changes via patches/diffs is preferred over overriding, allowing improvements in other parts of the files via opkg upgrade before you start. Johny Tenfinger wrote: Shortly: Let's write it ;) 2009/4/8, Lothar Behrens lothar.behr...@lollisoft.de: There is an idea rattling in my head about the following issue: Given I have a micro SD card and that would have all here, what is about a bootstrap mechanism to post install packages that are laying on that card to be installed, when a new image is started at first time? Like the autorun of a CD, this would help to ease the distro switch but keep my usual applications that otherwise have to be installed manually. This would include SSH settings, WLAN settings, look and feel, and what ever may possible. What about it? -- | Rapid Prototyping | XSLT Codegeneration | http://www.lollisoft.de Lothar Behrens Heinrich-Scheufelen-Platz 2 73252 Lenningen ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Autorun for SD card mechanism?
Ok, as the idea was good, more thoughts: 1.) Using the sd card to store jet installed application information is not good. Then it would only run the first distro switch. 2.) Keep in mind, that packages from the usual opkg may be installed in later releases. And it may or may not reinstalled. 3.) Using a database repository in the net to update a local database of applications that may installable without problems per distro. 4.) If a user add's an application with opkg, a choice could be made to activate autoinstall for later switches. 5.) If the application isn't in the database on the net, or the local copy, add it but mark it as untested. 6.) The database could be used for a hitlist of installed applications that would really used, because a reinstall could be counted. 7.) Untested applications that should be installed, could be complained about and a choice could be made. 8.) Feedback if successfully installed application makes problems. The user should be asked some time later and he/she may make choices as of like this: 'App1 is usable', 'App2 has problems on this distro' and so forth. That way, we get feedback of the most used applications, we see the quality in the installability and we may spot conflicts. Next, if a distro decides to add an application as default, it could be marked as installed by that distro. This leads propably to an update process per distro and thus a local copy (if there will be really some for offline installations) could either removed any time - by asking or the app on the card could also get updated. Keep in mind that there are issues with the applications data. If this data is not at least backed up to sd card, a distro switch may kill your data :-) Also keep in mind, that users don't want to give that feedback. We don't do it like some companies do collect their statistical :-) It is not easy and I don't like to only create a quick hack, that would not work at all. Lothar Am 08.04.2009 um 16:28 schrieb Pander: in the first boot, also make the most default choices of all when /media/card/post directory is found. e.g. English, Illume SHR theme, ..., next, next, next, finish ;) Johny Tenfinger wrote: Hmm... Maybe there is a place for some app... shr-firstboot :) It could also replace first boot creator from e17, which isn't very useful on Neos... 2009/4/8, Pander pan...@users.sourceforge.net: good idea. I already have all those files on SD but after each upgrade have to install them manually, which is annoying. I would suggest something like: 1) notify user to do an opkg update and opkg upgrade first 2) change to post installation directory cd /media/card/post 3) change to package directory and install all that is in there cd packages opkg install *.ipk *.opk cd .. 4) override files cd override [[copy all files to root of system, e.g. override/etc/blabla to /etc/blabla]] cd .. 5) path files cd patches [[apply all patchers to root of system]] cd .. off course documenting your changes via patches/diffs is preferred over overriding, allowing improvements in other parts of the files via opkg upgrade before you start. Johny Tenfinger wrote: Shortly: Let's write it ;) 2009/4/8, Lothar Behrens lothar.behr...@lollisoft.de: There is an idea rattling in my head about the following issue: Given I have a micro SD card and that would have all here, what is about a bootstrap mechanism to post install packages that are laying on that card to be installed, when a new image is started at first time? Like the autorun of a CD, this would help to ease the distro switch but keep my usual applications that otherwise have to be installed manually. This would include SSH settings, WLAN settings, look and feel, and what ever may possible. What about it? -- | Rapid Prototyping | XSLT Codegeneration | http://www.lollisoft.de Lothar Behrens Heinrich-Scheufelen-Platz 2 73252 Lenningen ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- | Rapid Prototyping | XSLT Codegeneration | http://www.lollisoft.de Lothar Behrens Heinrich-Scheufelen-Platz 2
Re: Autorun for SD card mechanism?
A directory called /media/card/post/linked with e.g. files like /media/card/post/linked/root/.cellhunter /media/card/post/linked/root/Maps/ the original /root/.cellhunter file and /root/Maps directory will be deleted and a soft link will be created to the ones in linked directory. Lothar Behrens wrote: Ok, as the idea was good, more thoughts: 1.) Using the sd card to store jet installed application information is not good. Then it would only run the first distro switch. 2.) Keep in mind, that packages from the usual opkg may be installed in later releases. And it may or may not reinstalled. 3.) Using a database repository in the net to update a local database of applications that may installable without problems per distro. 4.) If a user add's an application with opkg, a choice could be made to activate autoinstall for later switches. 5.) If the application isn't in the database on the net, or the local copy, add it but mark it as untested. 6.) The database could be used for a hitlist of installed applications that would really used, because a reinstall could be counted. 7.) Untested applications that should be installed, could be complained about and a choice could be made. 8.) Feedback if successfully installed application makes problems. The user should be asked some time later and he/she may make choices as of like this: 'App1 is usable', 'App2 has problems on this distro' and so forth. That way, we get feedback of the most used applications, we see the quality in the installability and we may spot conflicts. Next, if a distro decides to add an application as default, it could be marked as installed by that distro. This leads propably to an update process per distro and thus a local copy (if there will be really some for offline installations) could either removed any time - by asking or the app on the card could also get updated. Keep in mind that there are issues with the applications data. If this data is not at least backed up to sd card, a distro switch may kill your data :-) Also keep in mind, that users don't want to give that feedback. We don't do it like some companies do collect their statistical :-) It is not easy and I don't like to only create a quick hack, that would not work at all. Lothar Am 08.04.2009 um 16:28 schrieb Pander: in the first boot, also make the most default choices of all when /media/card/post directory is found. e.g. English, Illume SHR theme, ..., next, next, next, finish ;) Johny Tenfinger wrote: Hmm... Maybe there is a place for some app... shr-firstboot :) It could also replace first boot creator from e17, which isn't very useful on Neos... 2009/4/8, Pander pan...@users.sourceforge.net: good idea. I already have all those files on SD but after each upgrade have to install them manually, which is annoying. I would suggest something like: 1) notify user to do an opkg update and opkg upgrade first 2) change to post installation directory cd /media/card/post 3) change to package directory and install all that is in there cd packages opkg install *.ipk *.opk cd .. 4) override files cd override [[copy all files to root of system, e.g. override/etc/blabla to /etc/blabla]] cd .. 5) path files cd patches [[apply all patchers to root of system]] cd .. off course documenting your changes via patches/diffs is preferred over overriding, allowing improvements in other parts of the files via opkg upgrade before you start. Johny Tenfinger wrote: Shortly: Let's write it ;) 2009/4/8, Lothar Behrens lothar.behr...@lollisoft.de: There is an idea rattling in my head about the following issue: Given I have a micro SD card and that would have all here, what is about a bootstrap mechanism to post install packages that are laying on that card to be installed, when a new image is started at first time? Like the autorun of a CD, this would help to ease the distro switch but keep my usual applications that otherwise have to be installed manually. This would include SSH settings, WLAN settings, look and feel, and what ever may possible. What about it? -- | Rapid Prototyping | XSLT Codegeneration | http://www.lollisoft.de Lothar Behrens Heinrich-Scheufelen-Platz 2 73252 Lenningen ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org
Re: Autorun for SD card mechanism?
Yes, I agree with that when data should be used from sdcard, if there are these files. That would be the quick hack in my mind. But I brought up my points in case if there are applications for specific distros and versions that may be incompatible to each other? I don't know if the issue will make the whole thing too complex, but I thought to discuss about it. I have had a case where I gone back to an older version, but it didn't worked any more and I didn't know, wich versions do fit together. Am 09.04.2009 um 01:02 schrieb Pander: A directory called /media/card/post/linked with e.g. files like /media/card/post/linked/root/.cellhunter /media/card/post/linked/root/Maps/ the original /root/.cellhunter file and /root/Maps directory will be deleted and a soft link will be created to the ones in linked directory. Lothar Behrens wrote: Ok, as the idea was good, more thoughts: 1.) Using the sd card to store jet installed application information is not good. Then it would only run the first distro switch. 2.) Keep in mind, that packages from the usual opkg may be installed in later releases. And it may or may not reinstalled. 3.) Using a database repository in the net to update a local database of applications that may installable without problems per distro. 4.) If a user add's an application with opkg, a choice could be made to activate autoinstall for later switches. 5.) If the application isn't in the database on the net, or the local copy, add it but mark it as untested. 6.) The database could be used for a hitlist of installed applications that would really used, because a reinstall could be counted. 7.) Untested applications that should be installed, could be complained about and a choice could be made. 8.) Feedback if successfully installed application makes problems. The user should be asked some time later and he/she may make choices as of like this: 'App1 is usable', 'App2 has problems on this distro' and so forth. That way, we get feedback of the most used applications, we see the quality in the installability and we may spot conflicts. Next, if a distro decides to add an application as default, it could be marked as installed by that distro. This leads propably to an update process per distro and thus a local copy (if there will be really some for offline installations) could either removed any time - by asking or the app on the card could also get updated. Keep in mind that there are issues with the applications data. If this data is not at least backed up to sd card, a distro switch may kill your data :-) Also keep in mind, that users don't want to give that feedback. We don't do it like some companies do collect their statistical :-) It is not easy and I don't like to only create a quick hack, that would not work at all. Lothar Am 08.04.2009 um 16:28 schrieb Pander: in the first boot, also make the most default choices of all when /media/card/post directory is found. e.g. English, Illume SHR theme, ..., next, next, next, finish ;) Johny Tenfinger wrote: Hmm... Maybe there is a place for some app... shr-firstboot :) It could also replace first boot creator from e17, which isn't very useful on Neos... 2009/4/8, Pander pan...@users.sourceforge.net: good idea. I already have all those files on SD but after each upgrade have to install them manually, which is annoying. I would suggest something like: 1) notify user to do an opkg update and opkg upgrade first 2) change to post installation directory cd /media/card/post 3) change to package directory and install all that is in there cd packages opkg install *.ipk *.opk cd .. 4) override files cd override [[copy all files to root of system, e.g. override/etc/blabla to /etc/blabla]] cd .. 5) path files cd patches [[apply all patchers to root of system]] cd .. off course documenting your changes via patches/diffs is preferred over overriding, allowing improvements in other parts of the files via opkg upgrade before you start. Johny Tenfinger wrote: Shortly: Let's write it ;) 2009/4/8, Lothar Behrens lothar.behr...@lollisoft.de: There is an idea rattling in my head about the following issue: Given I have a micro SD card and that would have all here, what is about a bootstrap mechanism to post install packages that are laying on that card to be installed, when a new image is started at first time? Like the autorun of a CD, this would help to ease the distro switch but keep my usual applications that otherwise have to be installed manually. This would include SSH settings, WLAN settings, look and feel, and what ever may possible. What about it? -- | Rapid Prototyping | XSLT Codegeneration | http://www.lollisoft.de Lothar Behrens Heinrich-Scheufelen-Platz 2 73252 Lenningen ___ Openmoko community mailing list
