<jonesv>
Thanks a lot ocdtrekkie for looking into it. Feels like it's hopeless though, after a quick look it seems like kentonv thinks I screwed it up (which may well be, he clearly knows better).
<kentonv>
that's not what I said
<jonesv>
kentonv: sorry, I did not mean it negatively
<jonesv>
I can totally accept that I did not see the cleaner way and just duplicated code for no valid reason, that's plausible
<jonesv>
But then that's one more reason for me to give up. I won't spend another 10 hours trying to improve that, we already established that you did not have time for this :-). My goal was to contribute/help, not to make you lose 2h justifying why you don't have time for my stuff ;)
<jonesv>
Still it was interesting, and I really really like CapnProto (I read all the blog posts, mailing-list and HN comments I could find about Capnproto/capabilities) and that was a learning experience. So there's that!
<kentonv>
this is definitely one of those unintuitive and unfortunate truths about open source contributions... contributing to someone's project sounds like you're giving them a gift, but in ugly reality it's often creating work. :(
<kentonv>
my day job project extensively uses V8, Chrome's JavaScript engine. V8 is explicitly uninterested in patches that don't benefit Chrome. I understand why. It can be challenging for us, though.
<jonesv>
Yeah as I said, I learned that from Moxie in Signal. He was clearly saying that the only PRs he was interested in were those that took a lot of time outside writing the code (because he could generally write the code faster than reviewing it, and he would trust it more)
<jonesv>
So something that involved reproducing a bug, or testing a feature on 5 different phones, this was helpful. An insignificant feature was not, he would rather close the PR and rewrite it instead of reviewing.
<kentonv>
that makes a lot of sense to me
<jonesv>
And I actually did some of that for Capnproto: contributions to the build system are usually well accepted (e.g. support for musl, etc)
<kentonv>
indeed
<jonesv>
Now the thing is that my use-case for capnproto involves realtime stream (be it to play "rewrite webrtc in capnproto" for fun or to try to use it in robotics professionally)
<jonesv>
That's why I thought (naively, admittedly) that maybe I could help make a proof of concept (and it actually "works" for the tests I could do)
<jonesv>
Anyway, at least I get closure. This PR has been in my list for a year, and I was always kind of hoping for it to move forward xD. Now I can move on
<kentonv>
I actually do want this patch. But like 75% of my job is reviewing patches that I actually do want, but have to spend a huge amount of time going back and forth with people trying to get them to do it "right" (by my own incredibly obsessive standards, which they all hate my for).
<kentonv>
and I'm just always scared when I see a list of changed files all the way down the screen that I'm in for a lot of back and forth
<jonesv>
Well, the Capnproto codebase is super nice, so your obsessive standards seem to pay off ;)
<jonesv>
kentonv: yep, makes sense. And I can't pretend that I will require less back and forth than Cloudflare employees (I don't see myself as FAANG material :) )
<jonesv>
Well actually, since you're here. I did implement a UDP transport (for fun), and something that was not completely clear to me was the "capability" part. With TCP (and I guess UDS), is the capability part the connection?
<jonesv>
Like "I trust you have the right to use this capability because your network connection is in my list"? Because there is no token or anything being exchanged between the caller and the callee
<jonesv>
I was thinking that for UDP, I could "connect" the sockets on both end (using some mechanism), and that may ensure the "access control" part of the capability (if I can say it like this)
<jonesv>
Do I make any sense at all?
<kentonv>
I think you'd need some sort of encryption to avoid MITM attacks
<jonesv>
Sure, but that's valid for TCP too
<jonesv>
(I played with TLS for TCP, I guess dTLS would do for UDP)
<jonesv>
But I was wondering if, in terms of security, it's enough to "connect" UDP sockets
<jonesv>
Because when a TCP connection is closed, the other side sees it. But for UDP, I could imagine that an attacker kills the caller, quickly creates a socket using the same src port, and the callee would not make the difference (unless there is dTLS)
<jonesv>
Anyway, that's irrelevant ;). It's almost 3am here, time to sleep
<jonesv>
And sorry for the inconvenience, I really meant well :)
<jonesv>
I will just push my resolved conflicts tomorrow on the realtime branch (so that they exist somewhere), but after that I'll stop pushing to it, such that you don't get useless notifications ^^
<kentonv>
a MITM attacker can arbitrarily rewrite the communications, it could block packets, generate new fake ones, and so on, appearing to come from the legitimate peer address/port
<kentonv>
so you need an encryption mechanism that actually authenticates the packets as coming from the legitimate peer
<jonesv>
right, makes sense indeed
<ocdtrekkie>
jonesv: What things are you trying to build, out of curiosity?
<ocdtrekkie>
Although I suppose at 3am, bad time to ask for potentially a long answer.
<jonesv>
ocdtrekkie: I work with drones. Drones are typically connected to a ground device (where an operator can monitor what's happening and send commands, e.g. to takeoff or land)
<jonesv>
It's an interesting setup, because if the drone is connected over a radio, then that's not the typical internet link
<ocdtrekkie>
Neat! I have a drone I do not ever fly.
<jonesv>
e.g. TCP assumes that the physical layer below is fairly reliable, so that lost ACKs can be considered as congestion. Typically with drones we don't really have congestion problems, but it may well be that the drone is behind a building and so we lose messages
<jonesv>
So if for some reason the connection drops for 8s, we don't want TCP to slow down thinking "wow wow wow, there is no bandwidth here".
<jonesv>
Anyway. Most of the messages are the status of the drone (position, altitude, battery level, etc), which are exactly realtime messages. The drone sends them repeatedly, and we don't care about losing one
<jonesv>
But some messages need to be partially reliable (if I say "takeoff", I want to know that it will takeoff now, or never)
<jonesv>
I wanted to experiment with CapnProto in this setup: use the normal RPC for reliable messages (maybe not over TCP, rather a modified QUIC so that I can tune the algorithm in userspace)
<isd>
jonesv: have you tried a non-loss-based cca, like BBR?
<jonesv>
and use UDP or unreliable QUIC for those messages that can be lost
<jonesv>
isd: right now, we use a custom protocol called MAVLink, that does its own thing (made for non-IP radio links actually). But it has fundamental flaws, and it would be cool to be able to leverage gRPC or CapnProto or something. And since CapnProto is super cool (and the codebase seems nicer than grpc/protobuf to me), I wanted to look into that.
<jonesv>
And I just love the capability concept, let's be honest
<jonesv>
isd: so yeah, with Capnproto I was really looking for something that has the high-level RPC I want (RPC + realtime streams), and that I could tune at the transport level. And CapnProto is super well designed for that: it's easy to write my own transport and experiment
<jonesv>
(not sure if that answers your question. But BBR would go in the transport experimentation, which is the step after making sure Capnproto works high-level)
<jonesv>
I could obviously hack something around to use capnp-rpc only for the reliable messages, and some custom link sending capnp-serialized messages for unreliable. But I don't want to go for hacks, and it's a side project in my free time, I wanted to do it well
<jonesv>
Hence the need for realtime streams. Without that, capnproto is a no-go for this project of mine :(
<jonesv>
The other idea I liked was about pipelining commands (this does not exist in capnp but kentonv mentioned that in some hackernews comment I think): I'd like to be able to say `arm().andThen(takeoff()).andThen(goTo(latitude, longitude))` in my code, and have that be sent as "one message" (because obviously I care about limiting round-trips)
<jonesv>
But I could never implement that (I already failed the realtime streams xD), and nobody will ever need it I think. Right now the pipelining in capnp (IIUC) is an optimization and relies on reusing a return value
<ocdtrekkie>
If I could control my drone that easily programmatically I would probably fly it. 🫠
<jonesv>
ocdtrekkie: what drone is that? DJI something?
<jonesv>
(if I may ask)
<jonesv>
Many drones have some kind of API. DJI/Parrot have SDKs for instance. So you can really write an Android/iOS app to control your drone
<jonesv>
One thing that works well is to upload a "mission", which is a group of waypoints. The drone flies this mission and takes pictures of the ground regularly. Then from all those pictures you make a map or 3D model of the are
<ocdtrekkie>
jonesv: I have a Lynxmotion Hunter VTail 500.
<jonesv>
What kind of autopilot is there?
<ocdtrekkie>
Currently it's wired up with more or less a model airplane style RC setup. I have their controller for it but I never had time to tinker in setting it up.
<ocdtrekkie>
Quadrino. That's the thing I have I never programmed.
<jonesv>
Quadrino? Never heard of that. Does pixhawk/PX4/ardupilot/betaflight sound familiar to you?
<ocdtrekkie>
Several years ago when I had money I built it, flew it like three or four times, and now it takes up prized real estate in my basement. :|
<jonesv>
I wonder if they have their own autopilot (never heard of it, seems unlikely) or a fork of Ardupilot/PX4/BetaFlight (those are the 3 bigger ones, BetaFlight is more for racer drones)
<jonesv>
But say (hypothetically) you got a pixhawk board (that's the hardware board) and installed PX4 or Ardupilot (I work on PX4, actually ;) ), then it would talk MAVLink (that's the protocol used by both Ardupilot and PX4, which are two competing open source autopilot firmwares)
<jonesv>
(I wrote a protoc plugin that generates the API in those languages from a proto file, so another thing I would have been interested in would have been to write a similar thing in Capnproto that would generate a Kotlin API and the JNI code to call Capnproto C++ directly))
<ocdtrekkie>
MultiWii appears to be the software of choice for this board. But again, it's really old so I don't know if whatever that is is still a thing.
<jonesv>
ocdtrekkie: yeah I would really go for a pixhawk and ardupilot/px4
<ocdtrekkie>
If I had money and an idea I probably would get a new controller someday. The reason I got the VTail to begin with is it seemed very easy to add/remove/replace/upgrade things as technology developed. Rather than a prefab device.
<jonesv>
Yeah that makes sense. It's pretty fun to fiddle with those things. I had an RC foam plane, and installed a pixhawk on it with PX4, then played with radios, etc
<jonesv>
This is an example of my protoc plugin: https://github.com/jonasvautherin/protoc-gen-mavsdk-example. I know it's not brilliant/rocket science, but that's why I imagined looking into generating a Kotlin-JNI-C++ Capnproto library automatically
<jonesv>
Anyway, 0330 in the morning here, I really need to sleep
<jonesv>
Sorry for the spam ;)
<ocdtrekkie>
It's never spam if it vaguely relates to capnp. This channel is too quiet sometimes. ;) Have a good night.
yarmo has quit [Quit: yarmo]
<isd>
jonesv: capnp's pipelining isn't an "optimization" in the sense of a compiler optimization that you can't necessarily assume is going to fire. If you don't see code that's waiting on a result explicitly then you're not on the results.
<isd>
* you're not waiting on the
yarmo has joined #sandstorm
<TimMc>
kentonv: Sometimes I just want to make a PR against a branch that I'm reviewing. :-) I like that GitHub has made their "suggestions" feature that enables that in a small way.
<isd>
You can actually just submit a PR against the PR's branch. I have done this a couple times.
<TimMc>
*nod* It has never quite come to that yet, though.
<TimMc>
I guess it feels somehow improper to me, socially. I'm not sure why!
<kentonv>
I don't do that often but when I do I tend to just push commits directly into the reviewee's branch. Maybe that's rude.
<kentonv>
I really do think the ideal code review workflow would be integrated into my IDE rather than be a page in my browser.
<kentonv>
With the coming AI-pocalypse I wonder if that'll become even more important as we mostly spend our time reviewing AI-generated code rather than writing our own. (uuuuuuuuuughhhhh)
<ocdtrekkie>
I really like the "allow maintainer to make changes to this branch" setting. It feels like it makes sense.
<ocdtrekkie>
I know sometimes people will review and tell you to make some changes, but if they are trivial, it saves a LOT of time for the maintainer to just make them rather than noting what they should change, waiting days to months for them to actually make said change, and then merge it.
<ocdtrekkie>
It is probably good to let people fix their own problems if you are trying to teach the codebase/foster contribution, but if you just want to move things along... yeah.
<kentonv>
I'm not sure it's even good for teaching to make someone interpret your words back into code and get it wrong... better to just show them along with a little explanation and then have them review back
<kentonv>
it's of course bad if they don't actually read your changes
<isd>
It feels more polite to just merge, push fixes, and then mention them. But that requires it to be otherwise ready to merge.
<ocdtrekkie>
Fixing on branch leaves a cleaner master at any given commit, which feels healthier though.
<ocdtrekkie>
Though some people care more or less about that for different projects. My friend James likes to squash merge, which makes him very unusual, imho.
<isd>
Yeah, I tend to only do that on small projects. But you can also do the merge locally and fix before pushing, to avoid the intermediate state actually being master for a moment.
Ryuno-KiAndrJaen has quit [Ping timeout: 260 seconds]
isd has quit [Ping timeout: 252 seconds]
ptman[m] has quit [Ping timeout: 252 seconds]
ocdtrekkie has quit [Ping timeout: 260 seconds]
humanetech has quit [Ping timeout: 260 seconds]
LyreCalliope[m] has quit [Ping timeout: 248 seconds]
isd has joined #sandstorm
humanetech has joined #sandstorm
ill_logic has joined #sandstorm
humanetech has quit [Quit: Bridge terminating on SIGTERM]
isd has quit [Quit: Bridge terminating on SIGTERM]
ill_logic has quit [Client Quit]
Ryuno-KiAndrJaen has joined #sandstorm
ocdtrekkie has joined #sandstorm
humanetech has joined #sandstorm
ptman[m] has joined #sandstorm
ill_logic has joined #sandstorm
LyreCalliope[m] has joined #sandstorm
isd has joined #sandstorm
isd has quit [Ping timeout: 240 seconds]
ill_logic has quit [Ping timeout: 240 seconds]
Ryuno-KiAndrJaen has quit [Ping timeout: 246 seconds]
ocdtrekkie has quit [Ping timeout: 246 seconds]
LyreCalliope[m] has quit [Ping timeout: 265 seconds]
humanetech has quit [Ping timeout: 256 seconds]
ptman[m] has quit [Ping timeout: 264 seconds]
Ryuno-KiAndrJaen has joined #sandstorm
ill_logic has joined #sandstorm
isd has joined #sandstorm
ocdtrekkie has joined #sandstorm
humanetech has joined #sandstorm
ptman[m] has joined #sandstorm
LyreCalliope[m] has joined #sandstorm
xet7 has quit [Remote host closed the connection]
<TimMc>
Well, for squash-merging you'd generally want to rebase & squash the feature branch, and then fast-forward-merge master, so there's no intermediate commit on master.
yarmo has quit [Read error: Connection reset by peer]
yarmo has joined #sandstorm
mnutt_ has quit []
mnutt has joined #sandstorm
<Ryuno-KiAndrJaen>
<kentonv> "With the coming AI-pocalypse I..." <- I heard about integrating something voice into GitHub.
<Ryuno-KiAndrJaen>
Let me know if I shall take a closer look/share the link.
<ocdtrekkie>
The idea of using AI to generate things humans have to read and respond to feels borderline abusive to me.
<ocdtrekkie>
I do understand using generative AI to help illustrate or provide a start for a document layout, but expecting someone else to cope with the raw output of your AI tool feels no different than bot spam.
<TimMc>
What I foresee is that AI-generated text will gain acceptance and that people will start excusing random factual errors in communications. :-X
<TimMc>
(just like they excuse other tech glitches, except this time it's about meaning, not deliverability or availability)
<TimMc>
However, I don't think they'll excuse overly long and rambling emails. People are already prone to just skimming or deleting those.
<TimMc>
Similarly, if someone submits a PR with really weird code, I might give it some review but ultimately abandon it -- whether it was hand-written or horked up out of Codepilot or ChatGPT.
<TimMc>
Did you know that GitHub has a feature in Copilot that will try to detect and avoid outputs that match public code? It's only available for Enterprise customers. 🙃
<ocdtrekkie>
of course, because only enterprise customers can get in trouble for copyright infringement.
<TimMc>
kentonv: Oh, I actually might end up using Cloudflare Workers at work for a project to deploy Content-Security-Policy headers.
<TimMc>
(Transform Rules are the first choice, but neither is perfect for the use case, so we'll see.)
<kentonv>
TimMc, step 1, CSP, headers, step 2, the rest of your application? :)
<Ryuno-KiAndrJaen>
Figuring them out is a journey of its own