> > *I'll argue the opposite unless you have enough customer volume to have a > technical support department behind you.* > > *For most of my working career my product was generally a custom system > for a specific purpose and six instances would be a raging success, but the > systems were located on all three coasts. Having the development > and deployment images be the same has definite advantages when trying to > troubleshoot/repair issues via a phone call to the users, and prevents > "missing pieces" if rushing out to the remote site -- not quite so big an > issue now that about everything is available via Google & github, but most > of these systems were on an isolated network for security.* > > *I only worry about image size if it forces the next cost increment in > capacity, but in these days or $10-20 32GB uSD cards its not worth much of > my time to worry about keeping it small. If you need to stay in the eMMC > then its important, but in the short life of the Beaglebone Black its > already doubled once and likely will again at the next major revision.* >
This is why I'd have a "test jig" to duplicate exactly what's going on. If you control the hardware, and software. You should not need a large technical support group to figure the problem out. Then when you find the problem locally, you test locally on an exact production system by installing an apt package, if needed for the situation. On Fri, May 6, 2016 at 8:15 AM, Wally Bkg <wb666gre...@gmail.com> wrote: > > > On Friday, May 6, 2016 at 12:58:33 AM UTC-5, William Hermans wrote: >> >> william@beaglebone:~$ df -h / >> Filesystem Size Used Avail Use% Mounted on >> /dev/mmcblk0p1 1.7G 1004M 536M 66% / >> >> Thats also why I recommend to anyone who will listen. That they should >> create two different beaglebone images when developing. >> >> >> - One production image with only te bare minimum installed for the >> given project. >> - One development image with all the necessary dev packages >> installed. Like this one here that bloated from less than 200M to 1004M . >> . >> . >> >> Two main reasons. >> >> Why would you want to boat a production system needlessly. It can impact >> performance. >> >> - It's a potential added security risk. As the more you have >> installed, the more that is potentially exploitable. Merely a potential >> concern, and not necessarily fact. >> >> I'll argue the opposite unless you have enough customer volume to have a > technical support department behind you. > > For most of my working career my product was generally a custom system for > a specific purpose and six instances would be a raging success, but the > systems were located on all three coasts. Having the development > and deployment images be the same has definite advantages when trying to > troubleshoot/repair issues via a phone call to the users, and prevents > "missing pieces" if rushing out to the remote site -- not quite so big an > issue now that about everything is available via Google & github, but most > of these systems were on an isolated network for security. > > I only worry about image size if it forces the next cost increment in > capacity, but in these days or $10-20 32GB uSD cards its not worth much of > my time to worry about keeping it small. If you need to stay in the eMMC > then its important, but in the short life of the Beaglebone Black its > already doubled once and likely will again at the next major revision. > > -- > For more options, visit http://beagleboard.org/discuss > --- > You received this message because you are subscribed to the Google Groups > "BeagleBoard" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to beagleboard+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/beagleboard/4e38ddce-56e8-4a49-a0db-d150d0db6b1d%40googlegroups.com > <https://groups.google.com/d/msgid/beagleboard/4e38ddce-56e8-4a49-a0db-d150d0db6b1d%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CALHSORqo7mE2%2Bh1fQ9HqFr0qs_bCsujxqO68khyG-ii6e7aoDw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
