<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">On 12/04/16 15:58, Dirk Hohndel wrote:<br>
    </div>
    <blockquote
      cite="mid:348AACF6-1D4E-4265-8A9F-6FDF05E36F1B@hohndel.org"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
      <div>
        <div><br class="">
        </div>
        <div>Seriously, we need to very very very clearly separate two
          user groups:</div>
        <div><br class="">
        </div>
        <div>A) people who are comfortable installing debian on some
          random device</div>
        <div>and making all this work</div>
        <div>B) actual divers and users of Subsurface-mobile on their
          iPhone with no</div>
        <div>discernible knowledge of computers</div>
        <div><br class="">
        </div>
        <div>On every dive trip I'm on I somehow end up meeting about
          zero or one</div>
        <div>people in group A and everyone else is in group B. For
          group B we should</div>
        <div>pick ONE device, ONE solution, ONE way of doing this. Keep
          it as simple</div>
        <div>as humanly possible.</div>
        <div><br class="">
        </div>
      </div>
    </blockquote>
    Just wanted to throw this in as a suggestion:<br>
    <br>
    To make upgrades and upgrade-backout as seamless as possible for
    group B , how about having the main software as a complete read-only
    chroot image provided by the project? You'd have just enough on the
    bare metal to select the latest chroot image (or last known working
    on failure) and switch to it. That way it could have a one-click (or
    possibly no-click) upgrade. You could keep the last 2 or 3 images
    for backout purposes. This avoids the situation where devices get
    into a state that requires user intervention because one or more
    .deb fail to apply properly.<br>
    <br>
    apt-get could still be used by the project team to make the images,
    <br>
    <br>
    I think of this more like an Android or iPhone upgrade that applies
    a complete image rather than a desktop upgrade where you take
    individual packages, The difference though is keeping backout images
    and automatically failing back in case the new image fails load for
    some reason. <br>
    <br>
    This also has the advantage that someone troubleshooting will be
    able to know, for a particular version, exactly what software the
    user has on the device without worrying about which packages they
    may or may not have picked up along the way.<br>
    <br>
    The disadvantage is that a full image download is needed for each
    upgrade, which provides an intensive to make it as minimal as
    possible. Group A users can always side-load their favourite tools
    after updating.<br>
    <br>
    cheers,<br>
    <br>
    Tim<br>
  </body>
</html>