08:19:33 <dan-shearer[m]> #startmeeting Biweekly Update
08:19:33 <lumosql-meetbot> dan-shearer[m]: Meeting started at 2022-09-02T08:19+0000
08:19:34 <lumosql-meetbot> dan-shearer[m]: Current chairs: dan-shearer[m]
08:19:35 <lumosql-meetbot> dan-shearer[m]: Useful commands: #action #info #idea #link #topic #motion #vote #close #endmeeting
08:19:36 <lumosql-meetbot> dan-shearer[m]: See also: https://hcoop-meetbot.readthedocs.io/en/stable/
08:19:37 <lumosql-meetbot> dan-shearer[m]: Participants should now identify themselves with '#here' or with an alias like '#here FirstLast'
08:19:43 <dan-shearer[m]> Sorry
08:20:00 <rubdos[m]> bjk621[m]: even larger trouts
08:20:00 <bjk621[m]> #here Björn Johansson
08:20:02 <dan-shearer[m]> #meetingname biweekly update
08:20:02 <lumosql-meetbot> dan-shearer[m]: Meeting name set to: biweekly update
08:20:02 <rubdos[m]> #here Ruben
08:20:03 <Labhraich> #here Claudio
08:20:07 <dan-shearer[m]> #here Dan
08:20:47 <dan-shearer[m]> #topic Admin and What's Up
08:21:33 <bjk621[m]> nothing from me
08:22:14 <rubdos[m]> #info Ruben is working hard to get Martina funded starting January.
08:22:15 <dan-shearer[m]> #info Dan has continued to contact potential new team members, perhaps with some success. Let's see who turns up in this channel soon.
08:22:20 <rubdos[m]> I'll refrain from details, but I wanted to get that out there.
08:22:56 <dan-shearer[m]> #info GitHub is now a current mirror. There has been some contact from people as a result.
08:23:29 <rubdos[m]> I'll also try to get any speck of money that appears between now and January towards her, but I'm not very hopeful any more on that regard.
08:24:55 <dan-shearer[m]> Ruben De Smet: I think we should inform NLnet precisely what Martina is doing and how that fits in. You must have a concise summary paragraph by now. If it results in code, it may fit with their next round which closes in six weeks or so. And they have lots of new cash.,
08:25:10 <Labhraich> Problem with money is that now it's printed on plastic, not paper as it used to.  So it no longer grows on trees :-)
08:25:46 <dan-shearer[m]> #action Dan and Ruben De Smet to talk about short-term funding for University postgrads/staff.
08:26:12 <rubdos[m]> Labhraich: haha, good one :-)
08:26:30 <dan-shearer[m]> Labhraich: you've heard about a floating currency? That's plastic money for you.
08:26:30 <rubdos[m]> dan-shearer[m]: The funding I'm talking about is quite a bit more than short-term, but yes, we'll talk.
08:27:08 <dan-shearer[m]> Ruben De Smet: eg enough for one person for a year, to solve an immediate problem. That sort of thing
08:27:38 <dan-shearer[m]> Claudio, I believe you have been checking your bike and your tent and that is perhaps relevant to this chat?
08:27:40 <rubdos[m]> Yeh, that's something that NLNET can cover. I'm talking two people four years now.
08:28:15 <dan-shearer[m]> I have no idea how to fund VUB. But I'd like Martina around, yes please.
08:28:41 <Labhraich> I have decided that the bike needs some exercise and the tent needs some airing.  So I might take some days off looking for hills
08:29:20 <dan-shearer[m]> Labhraich: you have achieved immense things in LumoSQL, and really you definitely should go looking for those hills as soon as possible.
08:29:22 <Labhraich> Since I;m not getting much done anyway
08:30:09 <bjk621[m]> Sounds wonderful -- you have to tell us what you found
08:32:17 <dan-shearer[m]> Ok well. That's all the general stuff.
08:32:30 <dan-shearer[m]> Björn and I continue to work on strategy stuff and master plans etc.
08:33:00 <dan-shearer[m]> I wonder if Signal-related uses of LumoSQL deserve its own brief topic now?
08:33:26 <Labhraich> If there's something to report it may deserve its own topic - so it has a separate heading for later reference
08:33:44 <dan-shearer[m]> #topic Signal-related Uses of LumoSQL and Lumions
08:34:01 <rubdos[m]> Nothing from me, but I guess you can make an intro
08:34:25 <rubdos[m]> I'm currently also chatting with nanu-c about PNI and phone numbers in Signal.
08:34:46 <dan-shearer[m]> #info It is looking increasingly likely that an early user of LumoSQL and also Lumions will be one of the projects related to the Signal source code. And there is an opportunity to discuss it with Signal themselves too.
08:35:16 <rubdos[m]> All that while trying to kill fungus gnats that are flying around my head because they don't find food on my plants any more.
08:35:57 <dan-shearer[m]> #info Signal-related projects including Molly, Whisperfish, Sweet Lies (all people clustering around LumoSQL already) and several others.
08:36:13 <Labhraich> My plants are in the garden so I don't have that problem.  But yesterday a bird came in through a window and then couldn't find the way out of the house...
08:37:17 <dan-shearer[m]> #info this is LumoSQL as a drop-in replacement for SQLite/SQLCipher, and Lumions as a way for Signal data to be forwarded and stored even outside SQLite
08:38:30 <rubdos[m]> > Lumions as a way for Signal data to be forwarded and stored even outside SQLite
08:38:30 <rubdos[m]> That's still very hand-wavey, because Signal's e2e encryption is still way better than any SQL-PE system we can envision at this point, because the Signal system has more information than SQL does.
08:38:32 <dan-shearer[m]> #info The Signal codebase is exceptionally fast-moving. They are too busy riding a galloping horse to spend much time thinking about strategic solutions and there we may be able to help quite a lot. Because LumoSQL/Lumions is part of a strategy.
08:39:20 <dan-shearer[m]> Ruben De Smet: it will remain hand-wavey until we have a practical application to use to develop it, and funded developer time to make that happen, no?
08:40:05 <bjk621[m]> dan-shearer: interesting
08:40:18 <rubdos[m]> dan-shearer[m]: basically, yes
08:40:55 <dan-shearer[m]> Ok so, Dan's job is to stop this circular dependency of non-action relating to SQL-PE
08:40:58 <rubdos[m]> This sounds exactly like the Glycos situation, where semantics of the encrypted data have implications on the access control rules. Let's say that's what my post doc will be about.
08:41:02 <dan-shearer[m]> *SQL-PE applications
08:41:23 <rubdos[m]> kills another gnat
08:42:41 <dan-shearer[m]> Ruben De Smet: have you considered that the fungus might be inside your head, and so the insects are actually passing by your vision on the *inside*? And so when you think you are killing them you are just waving your hands? And that you just admitted to doing hand-waving anyway?
08:43:07 <rubdos[m]> That might explain a few things.
08:43:11 <rubdos[m]> any way, moving on?
08:44:36 <dan-shearer[m]> yes moving on
08:45:30 <dan-shearer[m]> ooh Björn sorry to mention this again but you have a sour toe to fix regarding expenses I should have mentioned in the first #topic
08:45:47 <bjk621[m]> Iknow
08:46:09 <dan-shearer[m]> #topic SQL-PE
08:46:44 <bjk621[m]> I have old you too many times I will fix this before next meeting. This is the last time
08:46:45 <dan-shearer[m]> #info Labhraich is having a holiday, but Ruben De Smet can do the internals of the logic required without linking to SQLite for now.
08:46:45 <bjk621[m]> *told
08:47:41 <rubdos[m]> #info Ruben has been writing code for the user authentication system that will eventually end up in LumoSQL.
08:48:03 <rubdos[m]> #info Concretely, this means there's now a key-based authentication for users, and a special role for the `root` user.
08:48:32 <rubdos[m]> In principle, the code base also understands privilege delegation, but this will be hidden behind abstraction, because the ABE system will not yet be able to cope with privilege delegation.
08:48:48 <dan-shearer[m]> #info the fact that this code is in Rust is not a problem because (a) Rust can link to C and (b) there is not very much code to re-implement in C anyway, because this is 80% design and 20% code.
08:48:54 <rubdos[m]> #url https://gitlab.com/etrovub/smartnets/sql-pe Code lives at
08:48:54 <lumosql-meetbot> rubdos[m]: Unknown command: #url
08:49:14 <dan-shearer[m]> you mean #link
08:49:17 <rubdos[m]> #link https://gitlab.com/etrovub/smartnets/sql-pe code lives here <-
08:50:00 <rubdos[m]> There's quite a few doc-comments in there, and I'll try to get that published somewhere too. The Rust doc generator is quite great
08:50:00 <dan-shearer[m]> takes his hat off to Ruben for his work
08:50:38 <rubdos[m]> For the role management system, we're at 95%+ code coverage through tests too, including quite a few failure and corruption tests.
08:51:11 <rubdos[m]> #info Next up is the privilege management system, where roles are assigned SQL priliveges, and those privileges are stored in a root-authenticated way
08:51:49 <dan-shearer[m]> LumoSQL has a problem at many levels communicating what it is for. SQL-PE will be no exception. People who understand privilege systems will of course see what is happening.
08:52:09 <dan-shearer[m]> But SQL-PE is going to see some very excellent science communication for the wider computer science public to understand it.,
08:52:16 <dan-shearer[m]> *going to need
08:52:27 <dan-shearer[m]> LumoSQL has a science communication problem.
08:52:35 <rubdos[m]> I'll also make an attempt to make it academically relevant, that should help too.
08:52:50 <rubdos[m]> anyway, that's it from me on a technical level, I think
08:53:02 <dan-shearer[m]> Oh I don't think your postdoc supervisors will care about academic relevance. Why should they?
08:53:06 <rubdos[m]> It felt great to be coding again, alas it was only one week out of too.
08:53:16 <rubdos[m]> dan-shearer[m]: Something something funding something.
08:53:40 <dan-shearer[m]> Oh ok then maybe I will let the university be academic. Since you insist.
08:53:49 <rubdos[m]> s/too/two
08:54:04 <dan-shearer[m]> Well done and keep coding.
08:54:15 <dan-shearer[m]> Ok that's SQL-PE
08:54:24 <dan-shearer[m]> There is almost nothing for APIs, but just a little
08:54:33 <dan-shearer[m]> #topic LumoSQL APIs
08:55:43 <dan-shearer[m]> #info Dan cares about replacing a lot of btree.c with a standard K-V API exported to the world and has done a preliminary review
08:56:24 <dan-shearer[m]> #info this is part of the recruitment Dan has been trying to do for LumoSQL... to make something called kvlite or libkvlite or something
08:57:40 <dan-shearer[m]> #info this would be quite a significant new piece of functionality for embedded developers everywhere, since it has decades of testing and very well known behaviours and failure modes
08:58:13 <dan-shearer[m]> #info But this is a bounded and separate project. It would also make LumoSQL internals quite a lot cleaner at the bottom.
08:59:20 <Labhraich> Yes, the LMDB backend would be more version-independent if nothing else, so lots of its conditional compiles (if SQLITE_VERSION is in this range) could disappear.  And of course any other backends we may decide to write
08:59:30 <dan-shearer[m]> #info Because a lot of LumoSQL seems to be about hardware differences, which are becoming more extreme not less with new kinds of storage, CPU and crypto-assist
09:01:00 <dan-shearer[m]> so we know with some degree of confidence that LMDB and SQLite Btree are better for different kinds of hardware. But there are more than two dimensions on hardware, and several more potential K-V store backends some of them with very interesting properties academically anyway.
09:01:47 <dan-shearer[m]> Which is why one relatively tiny little API could have a big effect on how well many robots, drones and mobile phones work. for example.
09:03:03 <dan-shearer[m]> Ardupilot users can see aircraft fly another kilometre when their video processing drinks less electricity, for example, and that's without anything to do with LumoSQL yet :-)
09:03:10 <Labhraich> There are other considerations which we haven't looked at because we can't (at present) measure them.  Maybe we don't care about the millisecond differences... but a backend ends up using a lot less energy than another for the same task, and when one considers battery-powered devices (or simply the need to stop wrecking the planet)...
09:04:18 <dan-shearer[m]> And when framerates improve on board drones then the decisions taken in real time improve. Etc etc. Which matters if the drone is looking for Labhraich lost on his bike in the desert.
09:04:30 <Labhraich> Being faster doesn't necessarily correlate - maybe it's slower because it uses a lot less CPU and that results in it running at a much lower power state.  The only way to know is... benchmark
09:04:31 <rubdos[m]> As long as you realize that log(n) operations are in microwatts-to-milliwatts range, and electric motors are in Watts to kilowatts.
09:04:59 <rubdos[m]> I would see interesting things happen on sensor networks though.
09:06:09 <dan-shearer[m]> Ruben De Smet: I think a lot of this is about second order effects of efficiency. If the aircraft responds more quickly because processing happened more quickly then it saves a lot of energy by being ready for the wind LIDAR said was coming.
09:06:46 <rubdos[m]> Has any SQL database or btree ever been part of a real-time deadline system?
09:06:50 <rubdos[m]> Not my expertise, must say.
09:06:56 <rubdos[m]> any way, this is getting philosophical
09:06:59 <rubdos[m]> We're in a meeting.
09:07:17 <dan-shearer[m]> real-time is a debatable term, but yes.
09:07:29 <rubdos[m]> real-time programming is a very well defined term
09:07:45 <dan-shearer[m]> Different amounts of real-time-ness on different parts of the processing pipeline.
09:08:12 <bjk621[m]> Agree w/ dan-shearer
09:08:16 <dan-shearer[m]> So a real-time system depends on the definition of "system" and that is where your comment about well-defined causes a half day argument :-)
09:09:05 <dan-shearer[m]> But in general, real-time means the following in my view:   Early answers are expensive, and Late answers are wrong  :-)
09:09:59 <bjk621[m]> We all know the difference between hard/soft etc realtime
09:10:00 <dan-shearer[m]> From the point of view of LumoSQL internals and SQLite deployments and real-time systems, I very much want to have a new person in #lumosql who is implementing a C API to Btree.c
09:10:20 <dan-shearer[m]> Do please everyone tell me if you think you know such a person.
09:10:43 <dan-shearer[m]> And that is end of topic from me anyway
09:11:03 <bjk621[m]> yes, no clear if I can attract him
09:11:15 <bjk621[m]> *not
09:11:52 <dan-shearer[m]> bjk621: I'm always happy to accept an introduction and have a chat.
09:12:14 <bjk621[m]> dan-shearer: talk to me offline
09:12:14 <dan-shearer[m]> ok next topic which must be very close to the last I think.
09:13:07 <dan-shearer[m]> quickly looks at notes from last couple of meetings
09:13:11 <bjk621[m]> I got h run at 1128 Brussels
09:13:53 <rubdos[m]> Oddly specific. If I don't get to say goodbye: goodbye and have a nice day and weekend!
09:14:26 <Labhraich> Well, there's still 14 whole minutes, but have a good weekend if you need to run in mid-sentence
09:14:30 <dan-shearer[m]> bjk621: I am free until 1127:14 Brussels so we can catch up.
09:15:19 <dan-shearer[m]> #topic Months of September and October
09:16:01 <dan-shearer[m]> #info LumoSQL is having exciting movement (Ruben and Martina! Yay!)
09:16:36 <dan-shearer[m]> #info LumoSQL has got a deliverable to make happen: The Demo
09:16:38 <rubdos[m]> #info Martina will most probably be visiting Brussels to write her thesis. We shouldn't expect her to write (a lot of) code any more during these months, and that is perfectly fine.
09:17:06 <rubdos[m]> we will also have funding news during these months, that's also quite great.
09:17:21 <Labhraich> I expect if she's writing up the thesis, she won't have time for anything else...
09:17:33 <dan-shearer[m]> #info And the first version of The Demo could be prototyped right now, if we assume SQL commands work which really don't exist
09:18:34 <dan-shearer[m]> #info We hope to have some more developer power appearing here in #lumosql:libera.chat . At least that is what I am spending a lot of time on.
09:19:20 <dan-shearer[m]> #info I am also spending time on the Science Communication problem, as everyone here knows. Because the world is full of genius work that nobody uses because nobody understands why it matters.
09:20:19 <dan-shearer[m]> #info Dan is expecting to travel at least a little for this Science Communication task, including to Sweden. Details unclear yet.
09:20:41 <dan-shearer[m]> #info if Dan is travelling then Amsterdam and Brussels are on the itinerary too.
09:21:00 <dan-shearer[m]> #info Dan has two more talks on LumoSQL topics
09:21:15 <bjk621[m]> You are welcome. Winter in Gothenborg is not for the weak
09:21:30 <rubdos[m]> bjk621[m]: Oh I'd love to experience that.
09:21:55 <bjk621[m]> -5C + 20 m/s wind
09:22:08 <rubdos[m]> I'm fine with -10, but the wind might do it indeed.
09:22:24 <bjk621[m]> the humidity ...
09:22:45 <dan-shearer[m]> It's +19 degrees in Göteborg right now. I had better visit this afternoon.
09:23:22 <Labhraich> I regularly had -10 and even -15 while growing up - but usually no wind.  On the other hand I used to go around without coat or gloves even in that temperature (I wouldn't be able now)
09:23:27 <dan-shearer[m]> Ruben De Smet: I propose the next sprint be in Göteborg in October.
09:23:45 <rubdos[m]> october being next month, or in 13 months?
09:23:55 <dan-shearer[m]> Labhraich: you have been to Hell, I saw the photos
09:24:28 <dan-shearer[m]> Ruben De Smet: what about mid-to-end October, on a Fri-Sat-Sun-Mon, with some relax time on Sat-Sun ?
09:24:30 <Labhraich> That was Hell frozon over... you can see the ice in the background (and I'm wearing a T-shirt and sunglasses)
09:25:31 <rubdos[m]> Problem is, teaching starts in October, and I've already got quite a few things in my agenda
09:25:31 <dan-shearer[m]> Well I know someone who seems to be part of the academic and startup mafia in Göteborg. I am sure we can arrange hosting for a sprint.
09:25:32 <rubdos[m]> I'd rather stay home a bit longer.
09:25:43 <rubdos[m]> I'll still see Italy and France the next few weeks.
09:25:44 <dan-shearer[m]> Teaching starts in October eh? Ok.
09:26:09 <rubdos[m]> half of September, but exercise sessions usually Oct
09:26:27 <dan-shearer[m]> Ruben De Smet: would you take an action to decide on when a fun but also work long weekend is possible? Assume travel funded.
09:27:04 <rubdos[m]> What about start-of-November? :'-)
09:27:25 <dan-shearer[m]> Ruben De Smet: Ok that sounds good. I will speak to my mafia representative.
09:27:30 <dan-shearer[m]> Oh... he is about to leave here
09:27:39 <rubdos[m]> Let's round up, I'd say :-)
09:27:43 <dan-shearer[m]> bjk621: goodbye! But this sounds good I think?
09:27:59 <bjk621[m]> I have no connections ...
09:28:00 <rubdos[m]> do you say that (rounding up meetings) in English, or was that Dunglish?
09:28:11 <dan-shearer[m]> bjk621: yes you do
09:28:17 <dan-shearer[m]> But if you don't, I do.
09:28:17 <bjk621[m]> I have to go. See you
09:28:26 <rubdos[m]> Bye Björn! 👋
09:29:27 <dan-shearer[m]> Ok this last section was really helpful. We have some aiming points.
09:29:58 <dan-shearer[m]> Labhraich: I am a bit jealous of your biking holiday.
09:30:59 <dan-shearer[m]> Ruben De Smet: "round up" has relevant meaning but you didn't use it correctly here. More later on tiny points of English if you wish but I think we should finish the meeting.
09:31:00 <rubdos[m]> Labhraich:  have you ever had Malawi Peppadew? I'm eating one now, and it's extremely sweet (baccatum, so expected) and very tasty, but I fear I've got non-true seeds because it feels 20k-50k SHU instead of the advertised 1k-2k.
09:31:06 <Labhraich> I haven't even started - first need to make sure the brakes are well-behaved etc.  THere are lots of hills here
09:31:08 <rubdos[m]> dan-shearer[m]: Yes
09:31:23 <rubdos[m]> > <@dan-shearer:matrix.org> Ruben De Smet: "round up" has relevant meaning but you didn't use it correctly here. More later on tiny points of English if you wish but I think we should finish the meeting.
09:31:23 <rubdos[m]> * Yes and yes
09:31:27 <dan-shearer[m]> #endmeeting