**** BEGIN LOGGING AT Thu Feb 20 02:59:57 2020 Feb 20 19:15:28 me0w Feb 20 20:14:08 BeagleBoard is in the GSoC 2020! Feb 20 20:43:52 Great! Feb 20 22:49:33 I envy future gsoc bb stidents Feb 20 22:52:52 Also, why there are so few security related projects? I thought security and privacy are trendy nowadays Feb 20 23:16:46 like containerized android Feb 20 23:19:09 ds2: is it possible even on bb-x15? Feb 20 23:19:26 embden_new[m]: I think so Feb 20 23:19:35 I wanted to do it but didn't have any time Feb 20 23:19:51 by containerize, I am not limiting it to hardware supported lock down Feb 20 23:19:58 same here Feb 20 23:20:26 though, I will have some time to participate (like mentor) in such a project Feb 20 23:20:35 I want to do it anyway someday Feb 20 23:20:45 * I want to do it anyway some day Feb 20 23:20:48 there is no good reason for android to be running on bare hardware; its security/privacy is a joke - network access is no longer flagged as a special permission...that's the very basis security issues!!! Feb 20 23:21:02 recruit a student =) Feb 20 23:21:20 ds2: ok, I think I can Feb 20 23:21:28 at least I can try Feb 20 23:21:51 i'm trying to get more AI stuff going Feb 20 23:22:07 the state of the BBAI is a joke Feb 20 23:23:12 running CNN's on the GPU would a nice one for someone to do Feb 20 23:23:18 ds2: I don't know much about AI. does bb use dsps? Feb 20 23:24:01 for ai Feb 20 23:24:06 embden_new[m]: the BBAI is mostly a reduced (HW wise) version of the x15 - the demo AI stuff runs things on the DSP and the video accs (EVE) Feb 20 23:24:39 the GPU is entirely untouched... the demo is horribly encumbered with layers and layers and could be a project in itself to sort out Feb 20 23:25:03 piles of C++ with OpenCV calls thrown in unnecessarily Feb 20 23:25:27 there is a nice AI model called YOLO that would be really nice to get going Feb 20 23:26:24 any students reading this... variants/subsets relating to those would be entertained :D Feb 20 23:28:46 ds2: there is a small mistake in wiki: there are over 6 different variants of YOLO (YOLOv1, YOLOv2, YOLOv2 Feb 20 23:29:01 YOLOv3 should be the last, I suppose Feb 20 23:29:13 (I don't remember my wiki pass) Feb 20 23:29:23 *nod* was in a hurry Feb 20 23:29:31 wanted to get something in there Feb 20 23:30:00 YOLOv3 for practical purposes can be eliminated due to memory requirements Feb 20 23:31:01 v2 or v2-tiny is probally the most practical.... if things can be improved to integer fps Feb 20 23:31:24 ds2: I will try get AOSP Android running on bb-x15. I just finished my paper, so have some spare time. Maybe then I will be able to propose some containerization project Feb 20 23:31:59 embden_new[m]: a non Xen based one is probally the best use of memory Feb 20 23:32:25 anything that has multiple kernels is too heavy, IMO Feb 20 23:32:42 ds2: especially since xen-based doesn't really work Feb 20 23:32:56 in a very initial state Feb 20 23:33:09 I will try kvm Feb 20 23:33:17 embden_new[m]: *nod* Xen is better if you need to have a RTOS on the side Feb 20 23:33:49 user space containers may be enough unless they changed it so zygote or whatever it is called now wants to be PID 1 Feb 20 23:34:32 what would be really cool is if we could create a libegl that maps all the calls onto a window surface Feb 20 23:36:48 ds2: can you expand? Feb 20 23:37:45 newer versions of android wants to use the GPU. libegl is the library that connects the GPU with an area of the screen. So --- Feb 20 23:38:38 by default today, the libegl used in Android (or equiv) sends the rending to the entire screen. if we can write/modify/hack libegl, we can redirect all of android to a window (or even an off screen buffer) Feb 20 23:39:10 w/o this, we would need to know more about the GPU to be able to share it with other stuff outside of Android Feb 20 23:42:03 sounds like not easy to implement thing to me Feb 20 23:42:34 maybe Feb 20 23:43:19 shimming in things via the dynamic loader may be a path but it'd take experiments **** ENDING LOGGING AT Fri Feb 21 02:59:57 2020