On 2016-04-12 16:58, Dirk Hohndel wrote: [..] >> Hence the best way to go is to just use the packaging system of the >> distro that gets chosen. > > So the CHIP uses a Debian based system. But as I said in my last two > emails, exposing that to end users is already declaring defeat.
Indeed, hence why SSH would not be (per-default :) exposed. They would get a button labeled "Upgrade". > Yes, we can use the Debian tools behind the scenes (and no, I have > ZERO interest in going back to the fights with distros, and ESPECIALLY > with Debian, on how to package things and what is and is not in accordance > to their ideology). But the user experience needs to be very very different. Fully agree. > This will require help from the CHIP guys to pull off (or from whatever > platform we end up using). I don't think they will be used. >>> The other thing is deployment. Initially, that’s simple, we provide disk >>> images. But then, what is the upgrade path? Connect to wifi and do git >>> pull? apt-get upgrade/update? Get a new disk image? That needs to be >>> thought about as well for devices like this. >> >> Very good questions and still at the right time. >> >> We should definitely have a list of requirements as one of the first >> things, as otherwise how do we know what we really want and who is going >> to be working on what (duplicate stuff or stuff that never gets used is >> rather an annoying downer for many people). > > http://trac.subsurface-divelog.org/wiki/SubsurfaceBox Great! >> Assuming that the small size, flexibility and capabilities of a >> Adruino/USB/BT 'stick' is likely too little for us, lets go for a >> 'bigger' device which can run a proper-ish Linux. > > YES. Please. Given the price point and capabilities of the CHIP I see > no reason to go to something less capable than that. Fully agree. >> As an initial list of things see below, (do we have a wiki or git repo >> where we could put this list in markdown or similar format, makes >> discussing easier...) >> >> The device: >> * a name ("OnSurface" ? :) > > Subsurface Box > > But of course this is open to discussion :-) I am not one to do a long bikeshed. A Poll would be the proper way to select this. >> * a case >> - mostly water-proof-ish >> - nice bright yellow plastic so it can't get lost > > please add to the wiki Done >> * selection of hardware [see note below though] >> - CHIP >> - Pi >> - other? >> >> * battery that can at least make it functional for "a day" >> - we assume you get to land at one point where it is dry >> and that you can charge the thing, but it should not be >> after an hour of usage, the battery should at least survive >> a day of going out and diving > > I have a few words about that on the wiki, feel free to expand What you wrote suffices for me ;) >> * Dive Computer connectivity >> - USB Host to Dive Computer >> - USB<->IRDA connector support >> - others? >> Likely USB is the minimum, and that then things can plug >> into it that actually connect to the DC. > > Linux gives us a wonderful starting point as all the devices will > just work and even the iRDA USB plugs usually are supported. > This will require some testing to ensure that the right modules > are loaded, but that's fairly straight forward Agree. >> * Connectivity between device and mobile: >> - Bluetooth LE >> - low throughput >> - would require custom things for transfering items >> + does not require switching WiFi on mobile device >> - WiFi for connectivity >> + high throughput >> + can use standard HTTP transfers etc >> - does require switching WiFi on mobile device >> (but see below: Home/Away switch) > > I have added this to the wiki (except for the home/away thing... to > me that is definitely a V2 functionality) Adding a 'future' section. >> * "OS" Selection: I'll stick to this Linux-based thing ;) >> but we'll have to select a "Distro", and this will >> also select what 'upgrade' options we have: >> - Debian >> - I am partial to this where possible >> simply because of 'apt-get update && apt-get dist-upgrade" >> - would mean we simply roll Debian packages in a >> 'addon' repo originally and if we can get them >> into mainline Debian there, for setting everything up >> - Depending on storage: small form factor might just >> need custom strip-down distro >> Could build this from components/kits offered by others >> eg using OpenWRT as a base etc. >> -> it does affect upgrade methods... >> - something else? > > I would be amiss if I didn't point out the Yocto Project as a way > to create an image, but realistically, I'd much rather build on top > of what the device vendor ships, in this case a simple Debian > distribution. Raspberry Pi also, thus if people want different hardware (as they already have one for instance) then that should not be too tricky to accommodate. Noted in Wiki. >> Then the actual work for binding stuff together: >> >> * Installation of (minimal?) Subsurface on the device >> - if Debian or other such system: packages! > > As I said before, forget Uemis (I certainly have) and just go with > the command line version of libdivecomputer. I have that working > already. And as Jef points out, if we transfer the binary data > instead of XML we also get super-dense data files that would > make things more feasible for BLE Makes sense, added to wiki. (XML fans will shout that one can do binary XML ;) [nope not one of those folks ;) >> * Upgrade system >> - if Debian or other such system: packages! >> >> * First-time Setup Interface >> - SDcard slot option: >> could have an program that writes a simple configuration >> file to that medium config can be on a partition formatted >> with FAT32 or something else that any computer can read >> This 'program' could just be a menu option in SubSurface >> as we have all GUI parts sorted out there already. >> - won't work without a computer >> - WiFi option: >> it should just become an AP when initially enabled >> the user then connects, gets an IP, connects to http://<ip> >> and gets a nice web interface for configuration >> - in combo with broadcast mentioned below, mobile tool >> could actually just be the configuration tool >> with some kind of REST interface on the device. >> - USB: >> - Would require a non-host USB port next to host USB >> - Requires a computer >> -> not a really good option > > So as I said, I'm talking to the CHIP guys about this. This is > something that needs support from whoever builds the device. > We could of course have some company assemble the boxes > and flash them with a custom image, but I'd much rather work > with NextThing on creating an easy way for all of the projects > running on CHIP to bootstrap. > > What I suggested to them is that CHIP should ship with an open > WiFi access point running and a web server to connect to and > then a simple web interface where you enter a URL from which > a package is then installed. Super easy for end users. That would be a really great method of doing this. And yes, 'out of the box' would be a great thing to have. I was thinking of just going down the DIY route... but if somebody can do the above, that would be pretty amazing. Actually, it would open up their platform for auto-installers of any kind of tools, just plug in in your CHIP, connect the wireless, and chose the function from a ChipStore. (google is not very friendly for searching for "chip" btw...) >> * Configuration Interface >> After setup we should be able to reconfigure >> Likely this will be a component of the Mobile edition when wifi >> or heck the full version; but with BE or SDCard this would be >> quite a different tool to do. > > My vision so far (and I need to add this to the wiki) is that we have > a simple command/respond system that works over BLE. There > isn't THAT much configuration that we need. Pick the dive computer, > transfer the last fingerprint we have. Download from dive computer. > Wait for that to finish. Transfer to Subsurface/Subsurface-mobile Yep. Very minimal. >> * "Home"/"Away" switch: >> - When switched to "Home" it will try to connect to the local >> home WiFi Network, that way it becomes available to the home >> network and one can use it that way, thus avoiding need >> to have to have your mobile device switch between the home-wifi >> and the device wifi. >> - When switched to "Away" it will be a AP, your mobile device >> can then connect to it and use it directly. > > V2 In the wiki marked as 'future'. >> * Device discovery (for WiFi) >> - Simple edition: allow the user to enter the IP/hostname of >> the device in the mobile tool >> - Broadcast packet on local WiFi: >> Likely UPNP packets are a good tool for that, but we can use >> whatever is good. This way tool can autodetect it. >> (this option should of course have the option of being disabled >> in the configuration, I hate broadcasting stuff myself...) >> * Security policy: minimal exposure of anything > > Interesting question. Since I am still hoping to convince everyone > of a BLE solution instead of a much more elaborate setup that > some here seem to envision, discovery becomes easy. BLE > advertisement. Connection. Go. If people are really worried that > someone else can download data from their dive computer we > could of course add a PIN but frankly... WHY? The attack surface is indeed quite minimal. We could have a option for that in the future where one could require a PIN though that is configuration time. >> Yes, that is a long list of things, but if we have the list we want, >> then people can say "I'll tackle that part" and together we can get >> there quite fast. > > That's why I started the wiki. :) >> Note that the hardware could just be a variety of things, having it >> based on Debian could just mean that somebody runs this on a cheap >> laptop (great for devel, but indeed then you do not really need a mobile >> version anymore), while others use a mini-device. Or the in-house >> edition that you have on your desk could just be a VM on a bigger device >> etc, while you keep the tiny one in your dive bag. > > Yes, we could also support Xeon servers for those who usually take > one on a trip :-) mmmm those are sometimes heavier than tanks, thus they do not come along on the heli ;) I meant the above more for development work, one does not want to cross compile all the time in a lot of cases. > Seriously, we need to very very very clearly separate two user groups: > > A) people who are comfortable installing debian on some random device > and making all this work > B) actual divers and users of Subsurface-mobile on their iPhone with no > discernible knowledge of computers Good separation. Added to requirements as that is very important. And yes, it should be a plug-and-play box first. Advanced features we can add in a V2 edition, hence those things go to that section. While on vacation I don't want to meddle to much with computer stuff anyway, as well, one is on vacation ;) > On every dive trip I'm on I somehow end up meeting about zero or one > people in group A and everyone else is in group B. For group B we should > pick ONE device, ONE solution, ONE way of doing this. Keep it as simple > as humanly possible. Full ack. > Yes, you can set up a git server on the box with automatic hook based > triggering of cryptographic signatures on your dive data that are then > uploaded to the Subsurface cloud. And nine pages of configuration > including ipv6 support and whatever else you can think of. Go ahead, > knock yourself out. Except for possible updates, the device does not need IP. In the config we can just have a "Enable IPv4" and "Enable IPv6" option. And even config can be done using BLE if wanted. > But that is for YOU and for three others in group A that can actually agree > on the same features and the same hardware to use and the same distribution > to use etc. But for everyone else we need something that is really, > really simple > and really really reliable and well tested. Otherwise why bother. I fully agree ;) Greets, Jeroen _______________________________________________ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface