raggi

Everyone loves to tout TTFB numbers for quic, but there's very little widespread reporting on throughput, particularly analyzed for a large number / wide breadth of real world customers.

This matters because for a lot of operating systems, UDP buffers are still tuned to nearly 1990s levels, and are insufficient to overcome BDP challenges. For CDNs / edge deployment systems such as Cloudflare/Fastly, this may not be "statistically relevant" for their customers, in that they're close to "statistically most" of their customers, however for users in locations where these organizations do not have anywhere near such a good presence (APAC, the islands, etc), their experiences are getting _far worse_.

Vertical scaling this language also gets into painful territory quite often, I’ve had to workaround this problem before but never with a thing that felt like this: https://github.com/tailscale/tailscale/blob/main/syncs/shard...

It looks great when the windows have no content and fit in any size!

Secure: fuchsias kernel is a “practically sized kernel” - many call it a microkernel but it doesn’t take that too far. The kernel retains control over memory allocation, facilitates and enforces IPC and maintains an enumerable set of processes and threads. The kernel does not implement any high level drivers, it contains very few parsers. It has a consistent set of interfaces to userspace that are relatively few. The component system design carves out the “root resource” very early in the boot process and moving pieces down to dedicated delegates with limited access scopes and limited responsibilities. The component system is loosely coupled to, but leans on the package system which along with the content addressed filesystem ensures that code which is executed is _exactly_ what was originally built and specified - if that is violated it does not run. The verified boot path combines these features providing an end to end cryptographic path from signed bootloader images to the fully booted operating system. Builds done by the team apply many modern security practices, with hardened toolchain features, about half the code (as of a few years ago, probably more now) in rust, most of the other half in professionally reviewed c++. Some of the early third party researchers who attacked the system found that while they could identify some bugs (that we fixed promptly), lateral movement through the system was extremely difficult.

Updatable: as mentioned above the package system maintains a content-hard guarantee. It reduces cost of isolation and versioning using artifact sharing (as a result of content addressing) between versions where unchanged. Isolation properties of the design completely eradicate DLL hell. IPC interfaces in the core system provide stable APIs and are designed and reviewed with care to manage the evolution story and enable component interchange due to no invasive unmanaged coupling between components. Many components have been replaced with v2+ over the years with little to no fuss. The preferred deployment design follows an a/b update strategy making updates extremely safe.

Performant: most components in the system are medium sized in terms of responsibility as compared to common alternatives or common extremes. This optimizes for low latency for related task data locality and computation while maintaining a lot of separation between major components. While IPC has a latency cost, a lot of user facing performance amortizes well due to the implicit multiprocessing thah can result. All core components are written in fast systems languages. There’s always more to do on performance with a nascent system, but the architecture is setup in a generally good place for modern computing topologies and some of the implementations are decently strong for their age.

Simple: as it is a whole operating system and it has its own flavors of things, there may seem like a lot to learn which sounds complex, but many of the independent components and/or layers have simple interface boundaries with often fairly clear constraints and boundaries, which simplifies many aspects of understanding as a whole. Similarly the appropriately medium sizing of the kernel, of components, of interfaces with a generally “good taste” of sizing manages the numeracy complexity to a good level also. It’s quite easy to build associative memory for the system architecture and the components. Years on from when I worked on it I still have good recall for a ton of the system - hell I have a better memory for parts of fuchsia than the code bases I work on every day since I left.

fuchsia.dev has literally hundreds of pages of detailed content, I’m not going to rewrite it all in an HN comment

> The fact that they are now starting to talk about it publicly now is probably a sign that they are looking to move beyond just IoT in the future.

You're reading too much into a conference presentation.

The team has been allowed to make conference presentations for many years, it's just that most folks haven't wanted to put in the personal effort. A few have in the past, one I know of was Petr: https://www.youtube.com/watch?v=DYaqzEbU0Vk

This is probably the most complete story told publicly, but there was a lot of timeline with a lot of people in it, so as with any such complicated history "it depends who you ask and how you frame the question": https://9to5google.com/2022/08/30/fuchsia-director-interview...

I don't think they were as tenable then as they are now.

When I was doing performance work on the platform one of the notable things was how slow some of the message passing was, but how little that mattered because of how many active components there are computing concurrently and across parallel compute units. It'd still show up where latency mattered, but there are a ton of workloads where you also basically hide or simply aren't worried about latency increases on that scale.

A counter case though, as an example, is building the system using a traditional C-style build system that basically spams stat(2) at mhz or these days ghz speeds. That's basically a pathological case for message passing at the filesystem layer, and it's a good example of why few microkernels which aimed at self-hosting made it over the line. It's probably possible to "fix" using modern techniques, but it's much easier to fix by adjusting how the compilation process works - a change that has major efficiency advantages even on monolithic kernels. Alas, the world moves slow on these axes, no matter how much we'd rather see everything move all at once!

You got the high drama stories with the timelines re-arranged to fit the narrative :D

Fuchsias underlying goals are to be a great platform for computing. This is distilled in its current incantation into a short tagline on fuchsia.dev: simple, secure, updatable, performant.

The details of how when and where Fuchsia might fit / gets exercised are nuanced and far more often about other factors than those which make great stories. Maybe there will be some of the good stories told one day, but that'll need someone from the team to finish a book and take it through the Google process to publish :D

In the meantime, here's Chris interview: https://9to5google.com/2022/08/30/fuchsia-director-interview...

Vitess came from YouTube

Step 1: echo $SHELL Step 2: should mention profiles Step 3: is likely confused by terminal emulators that do not start login shells so profile is not reread (this is also why you don’t have dozens of duplicate path entries all the time). Trial and error is misleading without knowing why login items are or are not reread. Step 4: adding these statements to rc’s will generally lead to duplicate entries for nested shells Step 5: starts nested shells, so prior instances of step 4 demonstrate the problem with step 4. A login shell can generally be started cleanly like exec env -I $SHELL -l

Problem 2: comes from an all too common choice not to understand profiles and login shells. This includes vscodes choices.

Problem X: adding empty string to your path. This has all kinds of bad outcomes.

the arguments from folks on the "architecture review boards" was that multiple connections are always bad and that developers can't be trusted. i'm willing to accept that they did get beat up quite a bit over power at various points when at times applications were a big part of the problem. That said this is also a gross misunderstanding of the problem and overall solution space, as well as very much gatekeeping.

The alternative to polling is unfortunately polling, which is what the article is about.

You can avoid polling for messages, but you have to send packets outbound regularly in order to maintain a NAT mapping & connection, so that the external side can send messages inward.

The latency is overcome this way, so latency is a solvable problem, but this need to constantly wake up a radio every <30s in order to keep a NAT session alive is a significant power draw.

In theory you might be able to avoid this with NAT-PMP / UPnP however their deployments are inconsistent and their server side implementations are extremely buggy.

What I want from platforms, and I fought for at one time in Google with no success: a platform API that provides applications a way to schedule packets when the radio turns on.

The mobile platforms in particular continue to assume that you can live with their high level HTTP stuff, and it's just not good enough. The non-mobile platforms largely don't even approach the problem at all.

About: https://opendaw.org/

deno has been somewhat pleasing in this space, it's not a perfect boundary though

Do you anticipate that:

> When GODEBUG=fips140=only is used, in addition to the above, cryptographic algorithms that are not FIPS 140-3 compliant will return an error or panic. Note that this mode is a best effort and can’t guarantee compliance with all FIPS 140-3 requirements.

Will need to be more complete/certain in order to pass certification? My gut says it would based on the requirements, but I don't know how the auditors would respond in practice.

This is tin-foil-hat speculation, but for example, if you observe a locality measurement protocol picking where it should connect to, but you already know all of the local sites of interest that are relevant, you might want to find remote sites of interest. If you manipulate the more open sampling protocol to lean toward that remote site, you can then observe where secured connections to which you're otherwise blind, connect to. Now you have new remote targets of interest.

Tailscale uses latency to pick home DERPs and I am re-evaluating it as we observe what appear to be manipulated STUN latencies for users in Asia particularly in or close to China. The latencies are often raised to over 300ms to affect this, and steer clients toward the US west coast. The reason for these manipulations is unclear, but it's easy to speculate.

You can just open a stream in the service worker and push events via postMessage and friends.

Another nice thing to do is to wire up a simple filesystem monitor for all your cached assets that pushes path & timestamp events to the service worker whenever they change, then the service worker can refresh affected clients too (with only a little work this is endgame livereload if you’re not constrained by your environment)

The number was set while Apache was dominant and common deployments would get completely tanked by a decent number of clients opening more conns than this. c10k was a thing once, these days c10m is relatively trivial

This, it works well in a service worker for example.

There’s no separate signing in use here except for the ssh connection, which can be trivially mitm’d in common targeted scenarios because of the lack of webpki and the lack of other preparations. SSHFP would help, but only if configured both in dns, and if the client is both configured to look for it, using secure dns, and the user understands the failure UX and doesn’t just bypass it. On DNS: DoH would help but it is only in widespread use in browsers. DoT would help but it is only in widespread use on android.

In addition to this a further scan of the code reveals it’s also using a btree index lookup for code comparison and no limitation on attempts, so it is likely that this is relatively trivial to attack with timing as well.

Trivialize mitm all you want, you say concerns of mitm are hyperbolic, I gave a practical example of a target rich environment and there are plenty more folks could come up with. SSH may have long been skirting the lack of a better host key distribution system, but this is largely a matter of luck, access and bespoke usage. These new deployments demonstrate a change on two of these factors, increasing risk substantially if this grows.

No SSHFP record, TOFU clients. This is not secure.

I wish people would stop trying to use SSH for things like this. PKI has features that are missing here and those features matter.

This is unsafe.

"but raggi, mitm before tofu is a really unrealistic scenario"

ok, well, consider that some large percentage of gas stations in the US have hardware installed to skim your credit cards. those same folks are perfectly well motivated to drop a wifi dns mitm in conference buildings (trivial). new tech conference, handful of credit cards as people gossip about exactly these kinds of things in the hallway track. the roi on these installs would be pretty high, because tech folks tend to have a high credit balance. so yeah, "totally unrealistic" (this is more about terminal.shop, but same principle here as soon as someone uses it for actual value).

I assume this will need to change the shared memory header protocol so either SQLite comes along for the ride or this is an incompatible ABI?

yep, the iphone is comparably terrible in this area, even with the myshake app

just wait until you see the real conspiracy

There’s a one-sentence implied claim in here that raii is the reason for c++ rejection and rejection of c++ implies rejection of raii.

The author is clearly unaware of the recent cleanup attribute infrastructure submitted on the c side of the kernel: https://github.com/torvalds/linux/blob/master/include/linux/...

Zig is a fun and interesting language in its own right, there’s really no need for this post-truth era style propaganda. Just focus on your own work

This article implies that batch allocations are some kind of panacea and that raii has no place there.

Neither of these implications have any case made for them, just links to other publications that do the same.

It also alludes to downsides but fails to define them, and also misses documenting any downsides associated with alternatives.

Despite deep familiarity with the space and understanding of both sides, I can’t really see it saying anything much at all in fact

Read and write a lot of projects. Early career you need to get out there and see things. If you find stuff others are working on too all the better (e.g. OSS but there are other things like charity or public projects too)