Go does. And it supports timeouts and cancelation.

> Golang use UTF-8 for in-memory string.

Nope. It’s just bytes with no encoding.

https://go.dev/blog/strings

Corrected.

There is no such thing as "just bytes" when it comes to Unicode. UTF-8 is a way to represent Unicode codepoints in binary.

But I agree that author's statement is wrong. Go stings are equivalent to byte slices.

Go strings are just bytes. There is no Unicode or encodings.

There's no WebRTC in Tailscale.

Isnt a derp server juat webrtc with minor changes?

You don't need the whole of WebRTC for NAT traversal, TURN/STUN will do the job.

I haven't used displays with under ~215ppi in over 10 years. I find these subpixel opinion discussions still ongoing very... quaint. :)

So you haven't used a 32 inch 4K monitor which is ~135 ppi? What do you get at that size, a 5K or 6K monitor? Not many of those available and they have specific requirements like higher display port or thunderbolt bandwidth.

There's also an entire world of users still on 720p and 1080p displays. They deserve better font rendering even if it doesn't affect us personally.

I haven't. I have 5K and 6K monitors. That's indeed privileged, but only for a bit until that's soon commonplace and cheap. So this all sounds like a very temporary problem at this point for something so subjective. Every time this topic comes up it's the same "but I like the look of $OS rendering the best" comments.

High PPI screens have been around for 10 years or so, and they still cost about twice as much as a standard PPI screen the same size.

Put yourself in the shoes of the average computer purchaser: Would you rather buy a high PPI monitor, or two standard PPI monitors? To me this is a no-brainer.

Maybe you can afford such a display. But I still like regular HD displays because they are cheap and functional.

My recent horror from some git work was discovering how git sorts its tree objects.

The docs just say to sort by C locale (byte-order sorting). Easy. Except git was sometimes rejecting my packfiles as being bogus per its fsck code, saying my trees were misordered.

TURNS OUT THERE'S AN UNDOCUMENTED RULE: you need to append an implicit forward slash to directory tree entry names before you sort them.

That forward slash is not encoded in the tree object, nor is the type of the entry. You just put the 20 byte SHA1 hash, which is to either a blob or a hash (or a commit for submodules).

So you can have one directory with directory "testing" and file "testing.md" and it'll sort differently than a directory with two files "testing" and "testing.md".

You can see a repro at https://gist.github.com/bradfitz/4751c58b07b57ff303cbfec3e39...

(So to verify whether a tree object is formatted correctly, you need to have the blobs of all the entries in the tree, at least one level)

I've had this exact bug happen to me when I implemented my git clone.

The way I found out was that Github kept rejecting my push, because as I later discovered, my git history was invalid precisely due to entries being sorted improperly due to the forward slash requirement. I could have solved this with the real git, but the point was to use my tool exclusively for version control from inception, so I just deleted the .git folder. So, my git history appears to begin near the end of the whole cycle. But I did manage to learn a lot, both about git and about the language I implemented it in.

> directory tree entry names

But... git doesn't really store directories, does it?

I wrote a longer comment saying this (deleted now since I was wrong).

Turns out that Git does somewhat store dirs (in form of trees). See https://git-scm.com/book/en/v2/Git-Internals-Git-Objects (section "Tree Objects").

To understand op's repro look at the last two lines (objects in the tree) in each of their command outputs, not the files shown in the first few lines.

What I think op means is that the `testing` tree pointed in their first example is sorted after `testing.md` even though it's only called `testing` because it's being sorted as `testing/` and `/` is > `.` bytewise.

I'm not at a computer right now but it would be nice to test it with files named `testing.` and `testing0` since they are adjacent bytewise and would show the implicit forward slash more clearly with the tree object sitting between them.

This makes me wonder why Git can't just store an empty tree for empty dirs.

EDIT: did the Gist https://gist.github.com/alvaro-cuesta/bd0234e3e1a66819c7e9e9...

Notice the `git cat-file -p HEAD^{tree}` outputs.

> This makes me wonder why Git can't just store an empty tree for empty dirs.

tl;dr: it can (see my other comment) and the empty tree is hardcoded. But since the index works with file paths and blobs, having no file means that there's no entry in the index

Yes it does, it just doesn't store empty directories.

It can store empty directories (actually, trees). It can't do normally because the index maps paths to blobs, an empty directory doesn't have a file to map to a blob and then `git add` will have no effect. Given that normally we write commits from the index content, then normally we won't find an empty tree.

You can run `git commit --allow-empty` with an empty index and the root tree will be the empty tree:

   $ git init
   $ git commit --allow-empty -m foo
   $ git rev-parse @^{tree}
   4b825dc642cb6eb9a060e54bf8d69288fbee4904

4b825dc is the empty tree. And a funny thing about it is that it is hardcoded in Git, and you can use it without having this object:

   $ git init
   $ git commit-tree -m foo 4b825dc642cb6eb9a060e54bf8d69288fbee4904
   $ tree .git/objects # you'll see that there's no file for the empty tree

This is a good reading about that weird object: https://matheustavares.dev/posts/empty-tree

You can perfectly easily put the empty tree object as a tree object's child, this just isn't supported and some parts of Git will break.

Congrats, Filippo!

Yes its been a long journey since the early boringssl versions a decade ago.

This is at est!

Because your switch is mapping a 4 tuple to a certain link and these people aren't, is my guess.

Pollution, advertising, and extra traffic all in one! Puke.

Yes.

I'm largely responsible for this, so I'll try to answer.

Technically it's not NAT64 today. Different prefix for one, but it's also not translated at the IP layer (yet). For TCP, we terminate the TCP in tailscaled and make a new TCP connection out and switch them together, so packets are not 1:1 end-to-end.

We also had grander plans for the 32 "site-id" bits in the middle there. Instead of just a 8-bit (now 16-bit) "site ID" number in there, you could actually put the 32-bit CGNAT IPv4 address of any peer of yours, and then access its IPv4 space relative to that node, without any configuration.

Say you have an Apple TV plugged in at home.

Then you're at a coffee shop and want to access something on your LAN and don't have a subnet router set up.

You should be able to `ssh 10-0-0-5-via-appletv.foo-bar.ts.net` and have MagicDNS map that "appletv" as the "Site ID" and put its 32-bit CGNAT address in, and then parse out the 10.0.0.5 as the lower 32-bits, and then have Tailscale route your packets via your home Apple TV node.

All subject to ACLs, of course, but we could make it a default or easy-to-enable recommended default that you could do such things as an admin for your self-owned devices.

So why it's called "4via6"? That was just kinda a temporary internal name that ended up leaking out to docs/KB and now a blog post, apparently. :)