It's a thin HTTP/2 and HTTP/3 tunneling protocol for TCP, UDP, and ICMP traffic.
It should be easy to write an independent implementation based on this specification provided you already have an HTTP/2 or HTTP/3 library. Pretty neat!
More or less, built on top of it with added udp/icmp.
When writing server and client a lot of time is consumed by additional features, not on implementing the spec itself. For instance, in order to be truly stealthy we have to make sure that it looks *exactly* like Chromium on the outside, and then maintain this similarity as Chromium changes TLS implementation from version to version. Or here’s another example: on the server-side we need to have an anti-probing protection to make it harder to detect what the server does.
We support both H2 and H3 and this is necessary. QUIC is not bad, but there are places where it either does not work at all or works too slow.
And one more thing, even though the code and spec is only published now, we’ve been using TrustTunnel for a long time, started before CONNECT_UDP became a thing.
We’re considering switching to it though (or having an option to use it) just to make the server compatible with more clients.
Ah, so you resolve domains before to apply the routes to the profile, I see. As per the spec, network extensions are not allowed to reroute traffic outside the tunnel, destinations set in the tunnel network settings must be routed inside the tunnel. This means that users have to know their domains upfront, the app cannot do this dynamically, if only to comply with apple rules.
Actually, no, we don't resolve them. We scan the incoming ClientHello before making a decision on where to route the connections. If the connection should be bypassed we make a connection by ourselves and proxy traffic. Implementing it that way requires having a TCP stack right in the client.
In Linux (Wayland) you can copy text from the terminal without pressing Ctrl+C at all. Just select the text. To paste it in another Window, press the middle mouse button.
This is called the Primary Selection and is separate from the Clipboard (Ctrl+C/Ctrl+V). IMO the Primary Selection is more convenient than the Clipboard.
That's an X11 thing that Wayland had to reimplement because it's so convenient. The problem is when pasting into the terminal something that another program copied into the clipboard. That's ctrl-shift-c.
I thought about remapping copy and paste to their own keys, possibly a single one. Maybe on the number pad, which I never use. Or remapping ctrl-c.
There's always Ctrl+Insert for copy and Shift+Insert for paste. I know that there's some laptops lacking an insert key, which is terrible, but for keyboard with an insert key the Ctrl/Shift + Insert combos are useful at times.
Especially because one does not have to push three keys with the same hand, which is not nice to tendons. I think I did that for a while time ago, then forgot about it. Thanks.
Yeah I know. I missed this for the first couple days, but didn't take much before forgetting it after the change to Windows. (anyway I keep using Linux at home)
But that doesn't go into clipboard history. And severely restricts what you can do between copying and pasting in general (very importantly makes it a pain to do replace (i.e. select+(implicit-delete+)paste)) as any intermediate selection before pasting destroys your Primary Selection. And if you realize you did that, recopying takes manually reselecting the text, or the otherwise-never-used ctrl+insert to recopy, instead of just repeating the same old ctrl+c as you always do with the clipboard in any sane application.
Of course still a nice option (esp. in terminals where the proper copy/paste are nerfed and selecting for editing is annoyingly not a thing), but far from a replacement for the proper clipboard.
Speaking for myself (although I suspect many others), I haven't used a mouse in well over a decade. To be clear, I am in the terminal all the time. So this is not a universal solution.
There's some secret sauce there I don't know if I'm allowed to talk about yet, so I'll just address the existing tech that we didn't use: most things either didn't have a good enough license, cost too much, would take a TON of ramp-up and expertise we don't currently have to manage and maintain, but generally speaking, our stuff allows us to fully control it.
Entirely programmable storage so far has allowed us to try a few different things to try and make things efficient and give us the features we want. We've been able to try different dedup methods, copy-on-write styles, different compression methods and types, different sharding strategies... All just as a start. We can easily and quickly create a new experimental storage backends and see exactly how pg performs with it side-by-side with other backends.
We're a kubernetes shop, and we have our own CSI plugin, so we can also transparently run a pg HA pair with one pg server using EBS and the other running in our new storage layer, and easily bounce between storage types with nothing but a switchover event.
> would take a TON of ramp-up and expertise we don't currently have to manage and maintain
But you think you have resources to maintain a distributed strongly-consistent replicating block store?
The edge cases in RDB are literally why Ceph takes expertise to manage! Things like failure while recovering from failure while trying to maintain performance are inherently tricky.
I was struck by how similar this seems to Ceph/RADOS/RBD. I.e. how they implemented snapshotted block storage on top, sounds more or less exactly the same as how RBD is implemented on top of RADOS in ceph.
One of the problems with Ceph is that it doesn't operate at the highest possible throughput or the lowest possible latency point.
DAOS seemed promising a couple of years ago. But in terms of popularity it seems to be stuck. No Ubuntu packages, no wide spread deployment, Optane got killed.
Yet the NVMe + metadata approach seemed promising.
Would love to see more databases fork it to do what you need from it.
Or if folks have looked at it and decided not to do it, an analysis of why would be super interesting.
I'm the presenter of the talk, but not an io_uring kernel developer or security expert.
The io_uring implementation is complex and the number of lines of code is non-trivial. On the other hand, as code matures and the number of bugs being reported falls, the trade-off between functionality gained and risk of security issues changes. More people will decide to use io_uring as time passes. People already rely on much larger and more complex subsystems like the network stack or file systems.
QEMU is a Software Freedom Conservancy member project like Git, OpenWRT, and many others. You can donate through the Conservancy link you posted and mention which project you wish to support.
io_uring is available from RHEL 9.3 onward. The catch is that it's disabled by default and needs to be enabled at runtime via the "kernel.io_uring_disabled" sysctl.
The Linux RWF_DSYNC flag sets the Full Unit Access (FUA) bit in write requests. This can be used instead of fdatasync(2) in some cases. It only syncs a specific write request instead of the entire disk write cache.
It looks plausible: XFS's xfs_dio_write_end_io() updates the on-disk file size. Do you have a link to documentation that confirms this is true for Linux or POSIX filesystems?
Edit: POSIX 1003.1-2017 defines fdatasync(2) behavior in 3.384 Synchronized I/O Data Integrity Completion, where it says "For write, when the operation has been completed or diagnosed if unsuccessful. The write is complete only when the data specified in the write request is successfully transferred and all file system information required to retrieve the data is successfully transferred".
So I think POSIX does guarantee that a write at the end of the file with O_DSYNC/followed by fdatasync(2) (and therefore, Linux RWF_DSYNC) is sufficient. Thank you for pointing out that RWF_DSYNC is sufficient for appends, vlovich123!
Not really, RWF_DSYNC is equivalent to open(2) with O_DSYNC when writing which is equivalent to write(2) followed by fdatasync(2) and:
fdatasync() is similar to fsync(), but does not flush modified
metadata unless that metadata is needed in order to allow a
subsequent data retrieval to be correctly handled. For example,
changes to st_atime or st_mtime (respectively, time of last access
and time of last modification; see inode(7)) do not require
flushing because they are not necessary for a subsequent data read
to be handled correctly. On the other hand, a change to the file
size (st_size, as made by say ftruncate(2)), would require a
metadata flush.
The article mentions getting SPEC CPU running but doesn't share performance results or scalability results (now the CPU can decode twice as many instructions, etc). Can someone who has been following the research in this area share some results?
It's a thin HTTP/2 and HTTP/3 tunneling protocol for TCP, UDP, and ICMP traffic.
It should be easy to write an independent implementation based on this specification provided you already have an HTTP/2 or HTTP/3 library. Pretty neat!
reply