I have some patches saved up coming your way once I leave my current employer, who doesn't allow external open source contributions. Though that is not for a few years probably.
Love the libraries BTW. Thank you for all of your hard work.
I feel like it'd be kinda a jerk move to contribute anonymously when you know that might create an IP issue for an open source project. Even if the code truly has no IP issue, legal attention from an litigious company would likely be devastating to even a well resourced project.
Well the idea is that you determine the intention of the “IP issue” and act accordingly:
If there is an actual IP issue then even waiting after you’re out of the company will not resolve said IP issue. If you’re using your employer’s IP then waiting is unlikely (both legally and especially morally) to magically resolve it - it’s still your employer’s IP.
If it’s just to avoid red tape but otherwise the IP is yours and has nothing to do with your employer (aka you could’ve done it just as well even if you weren’t at your current employer, and your employer’s competitive advantage is not based on having a good WebDAV implementation) then it should be fine and you’re just taking a shortcut to save time on both sides.
Basically, if your employer is a vendor of WebDAV libraries, yeah of course there’s a (legal, or a least moral) issue. If not, then all fine.
(Obviously this is just opinion and not legal advice - but legality only matters if they can figure out who did it ;)
I think the situation your missing is when the employer has a much much more aggressive stance to IP. Even if you are 100% confident that your contribution doesn't violate your employer's IP, they can still sue and ruin your life.
Some employers have an unbelievably unreasonable interpretation of non-compete and IP. They think they own everything their employees do, and even though they're wrong. That doesn't stop them from ruining you and whatever unfortunate open source project they set their sights on with vexatious litigation.
The blog says that in regard to finding bash with env. My reading is that it does not make the same claim regarding finding go with env. bash is commonly found at /bin/bash (or a symlink there exists) as it is widely used in scripts and being available at that path is a well known requirement for compatibility. Go does not so much have a conical path and I have personally installed it at a variety of paths over the years (with the majority working with env). While I agree with the author of the blog that using env to find bash may or may not improve compatibility, I also agree with the parent comment that using env to find go probably does improve compatibility.
The main use-case is different: gRPC and Cap'n'Proto are designed for networked servers, while D-Bus and Varlink are designed for local IPC. Varlink is a lot simpler than other alternatives.
It's JSON with some simple idea of RPC added to it. With the main idea apparently being that it is human-readable.
We've been using Varlink for one project, but I've never found myself in a situation where I had any benefit from the data being JSON. You rarely read the raw data. But compared to gRPC or CapnProto, you lost compile-time type checking and now you need 10mins of testing a vending machine before you get a "key not found"-error because you missed one spot on renaming.
Also, I've written varlink-cpp building on asio and nl-json at some point: https://github.com/wolletd/varlink-cpp.
But as our varlink usage declined, it never found much usage and isn't maintained.
"you lost compile-time type checking" makes it sound like you haven't been using code generation? Varlink has an interface definition language which makes everything type-safe.
Simpler is pretty subjective. A lot of people have already ingrained the complexity of grpc and/or capnproto. And more importantly, there are a lot of well maintained libraries for those protocols.
At the end of the day, local or remote, it is all just pushing data over sockets, no?
oh there is a wide range of IRC clients for the terminal indeed. The project here was to implement bubbletea/lipgloss. Its like CSS for terminal UIs! Check it out when you can, pretty neat visuals.
reply