**** BEGIN LOGGING AT Sun May 10 02:59:57 2020 May 10 08:42:12 tlwoerner: its something to think about and the bandwidth isn't free, I'm just not aware its a problem right now. Stats are a challenge May 10 13:51:57 tlwoerner: I think you're overestimating the number of people who'd care to download old source. AFAIK the other significant build from scratch projects have their own mirrors, and distros have package source repos, so it's IMO hard to see imagine any significant non-Yocto use May 10 15:43:26 I'm curious, what do you people use for communication between different embedded devices? HTTP? Websocket messaging? Raw TCP? ZMQ? Some broker-based system like RabbitMQ/MQTT? May 10 16:51:15 rangergord: Depends entirely on the application and the use case May 10 17:00:58 paulbarker, sure, but what's your go-to for stuff for inter-device communication, on a LAN? May 10 17:01:38 I've used HTTP and raw TCP in the past, looking at messaging libs with multi-language clients right now May 10 17:01:59 rangergord: Depends what you're sending, there's no more general answer than that May 10 17:02:16 Right now I'm using ssh May 10 17:03:49 I was talking about communication between daemons on different embedded devices. There's general answers for that, SSH isn't one, unless your idea of IPC is "I'll ssh to the other device and write to a file that the other device then reads" May 10 17:04:23 Sorry, I assumed it was obvious from the context May 10 17:04:42 rangergord: There aren't general answers. One of my clients right now is using a custom UDP protocol, another uses MQTT, both are appropriate for their use case May 10 17:05:35 there you go. That's 2 approaches you used. May 10 17:07:43 Should I have phrased it as "what's your personal preference when multiple approaches work"? May 10 17:09:04 rangergord: I interpreted your question as looking for a universal answer, may have been wrong there May 10 17:09:25 It really depends on what guarantees you need, what your data rate is, whether you need encryption, etc May 10 17:09:39 And whether you need to interoperate with something else May 10 17:10:15 If I was implementing both sides of the link I'd look at protobuf or cap'n proto May 10 19:46:04 RP: gcc10 is your way now ! May 10 19:46:53 RP: I have kept defaults to be -fcommon for now, so we can iron out other issues first May 10 19:47:45 once all is well, then we can unplug the default setting and use -fno-common since there will be a lot of recipes which will need to be ported I thought its best to serialize the work May 10 19:48:48 let the ICE begin! May 10 19:52:13 well, it is 10.1 and not 10.0 -- so maybe less ICE and more slush? May 10 19:56:51 yeah May 10 19:57:08 I have trickled most of patches already May 10 19:57:28 so not expected surprises but tough ones for sure May 10 19:57:38 lets see what AB throws at us May 10 19:59:23 already seeing kernel 4.9 build failures but thats BSP problem in core we have 5.x which should work ok May 10 20:00:52 couple of months ago I had world build successful locally with wip gcc recipes at that time but month is a long time May 10 21:07:06 khem: this should be interesting :) May 10 21:30:47 khem: upgrading my build machine to F32 for use as a potential victim ;) May 10 23:32:28 khem: master-next running with those in May 10 23:33:30 * paulg_ puts some popcorn on **** ENDING LOGGING AT Mon May 11 02:59:57 2020