Since we have a couple of tailscale employee here :

It would be nice to have an easy way to define a multi node proxy. Right now i have several devices in my network which i can't install tailnet directly on. For each, i have to create a seperate container for each (since i tailscale node can't share network namespaces).

How would this work in practice? Also, how are you using your sidecars - socks proxy?

That was my thinking as well. I got the unify fiber gateway specifically for unify teleport and vpn integration.

I find tailscale to be simpler, more reliable and cover my needs better. I am pretty sure that have i known about tailscale before, i wouldn't have got the unify gateway.

I still love my unify though, dashboard galore

> A device can advertise subnets, and can route them through tailscale

This is still L3 layer though. One the main use case of L2 is proper DHCP propagation and avoid subnet collisions. I do not think that this matters in practices though. Only a limited amount of user facing service require proper L2 emulation (apple TVs ?)

Or anything that uses multicast. The idea is you want homoiconic networking behavior and portability between local and remote. Hacking in special routing and subnets in L3 doesn’t give you that.

Or use multicast routes...

> Glazing as a service is a hell of a drug.

You my friend made my day.

> like add jj workspace support

care to share a pr :)

It's not anywhere near making PR ready (and never will be) but here is the branch [1]. I make no promises on it's functionality, and I only periodically rebase Herdr's latest over it. I have been using the jj change for awhile though with no issues. So YMMV.

You can also see the combined output of all my changes at [2], which Jujutsu makes so damn easy via megamerges.

1: https://github.com/giodamelio/herdr/tree/jj-workspace-migrat...

2: https://github.com/giodamelio/herdr/tree/combined-branch

> You're getting confused between lifetimes (the static analysis that prevents use after free and similar errors) and lifecycles (more commonly discussed under the heading of ownership) which determines when objects (and thus memory) are allocated and deallocated. Ownership is

That's a semantic distinction which does not matter in the point OP is making. And contrasting rust static approach to general GC.

Sadly it does not. There are both a discussion about support for non-git vcs (https://github.com/ogulcancelik/herdr/discussions/522) and about jj specifically.

Hopefully any of those get some traction

I did find a plugin at least

Is the information actionable ?

Even if you couldn't prevent your death, knowing when it happens makes timing and planning a lot of other things much easier.

No, in this scenario no matter what the death would happen exactly as you see.

I felt the same for a while after switching to jj. I think using the word "commit" in jj is creating a lot of confusing. The snapshotting is closer to auto-save in your favorite editor. In does not change your ability to version and save your work. It's just a savety net for quick undo

It is called that because it is literally a git commit. jj might change it to “revision”, though, we’ll see.

Additional complexity ? jj just increase the frequency of snapshots. it does not fundamentality the complexity of the system

The one thing I do like about git’s staging area is that it’s truly useful for reviewing a bunch of changes (bulk actions or automated tools). Go over the change chunk by chunk and stage what matters (magit makes that extremely quick.

That could be probably done by jj. But the git’s way is already fine for me.

Yes, jj does make this very nice and easy. It’s the same idea as git, except that “the index” is just another anonymous change, not a distinct feature.