DAlperin

One of the cofounders it seems https://atomicsemi.com/about/

I think the next sentence clarifies pretty well.

In this case, what’s dropped is &mut future1. But future1 is not dropped, so the actual future is not cancelled.

(I used to work at Fly, specifically on the proxy so my info may be slightly out of date, but I've spent a lot of time thinking about this stuff.)

why can't every proxy probe every [worker, not application]?

There are several divergent issues with this approach (though it can have it's place). First, you still need _some_ service discovery to tell you where the nodes are, though it's easy to assume this can be solved via some consul-esque system. Secondly, there is a lot more data than you might be thinking at play here. A single proxy/host might have many thousands of VMs under its purview. That works out to a lot of data. As you point out there are ways to solve this:

One could reduce _average_ bandwidth a lot by having the proxies mostly send some kind of "send changes since <...>" or "send all data unless its hash is <...>" query.

This is definitely an improvement. But we have a new issue. Lets say I have proxies A, B, and C. A and C lose connectivity. Optimally (and in fact fly has several mechanisms for this) A could send it's traffic to C via B. But in this case it might not even know that there is a VM candidate on C at all! It wasn't able to sync data for a while.

There are ways to solve this! We could make it possible for proxies to relay each others state. To recap: - We have workers that poll each other - They exchange diffs rather than the full state - The state diffs can be relayed by other proxies

We have in practice invented something quite close to a gossip protocol! If we continued drawing the rest of the owl you might end up with something like SWIM.

As far as your second question I think you kinda got it exactly. A crash of a single corrosion does not generally affect anything else. But if something bad is replicated, or there is a gossip storm, isolating that failure is important.

(I used to work at fly on networking)

Fly has a lot of interesting networking issues but I don't know that like, the actual routing of packets is the big one? And even in the places where there is bottlenecks in the overlay mesh I'm not sure that custom FPGAs are going to be the solution for now.

But also this blog post isn't about routing packets, it's about state tracking so we know _where_ to even send our packets in the first place.

That’s the name in the Arabic text hallucinated by the model :)

The story here isn't that they've invented a new format for user defined indexes (the one proposed here is sort of contrived and I probably wouldn't recommend in production) but rather demonstrating how the user defined metadata space of the parquet format can be used for application specific purposes.

I work on a database engine that uses parquet as our on-storage file format and we make liberal use of the custom metadata area for things specific to our product that any other parquet readers would just ignore.

For what it’s worth I don’t think we entirely disagree: it has at times felt absurd that it didn’t make as much money as it maybe otherwise could. We made a bet that the type of cloud platform we wanted to build could be well served by GPUs. It wasn’t as good a bet as we thought. There is probably a different type of cloud product we could build that would be better set up to sell gpus but we are still committed to the primitives our machine product has to offer.

Super neat! Does the v2 branding mean that the more "fully featured" observability product is going away? Or is it all going to be rebuilt on top of clickhouse?

We have to invest in fighting fraud and abuse anyway, such is the public cloud business. We don't intend to diminish user experience in service of fighting it.

we can steer them to an area that's easy for us to drive out and pick them up.

What does this look like in practice? As you mentioned I know you don't really have any lateral control, but I imagine you can wait for it to overfly somewhere convenient to descend?

Fwiw Teenage Engineering is a design firm who was originally contracted by Rabbit to design the physical device. I don't think they had anything to do with the functionality.

Also to add, we already have lots of customers who use this model.

This is super cool! Do you have any plans to support on-demand image building like the now defunct https://ctr.run? It seems like with your speed it's kind of a perfect match.

Hah I've got my own backlog of side projects, don't tempt me I'm like a year behind on it :). If you ever get around to building it or something like it I'd love to hear about it. You should check out tools like https://github.com/nocodb/nocodb which expose a spreadsheet like interface on top of a database.

The problem appears less when creating new tables, creating tables is relatively safe. But let's say in your one table per db you keep track of a few things (columns). For example you have a column for the name of the sheet and another column for the time it was created and some other miscellaneous columns. Later on once you have a hundred users or so you get a persistent feature request: keep track of the time it was last updated. You write up a simple migration, it looks something like

  ALTER TABLE your_table ADD updated_at TEXT;

That said I do really like your idea, I've gotten into sqlite a lot lately (I work on the database team at Fly.io), I'm just responding to you questions specifically about migrations.

As fly apps v2 becomes more stable the docs will continue to improve. Watch this space :). As for the graphql, it's a bit of a thorny situation. The graphql exists primarily to service our needs internally and as such has no guaranteed contract. Unfortunately, however, for some things that's the only API that exists. The autogenerated docs in the playground are pretty good actually though. That said, we are working on improving our rest api so more things will be available there.

Yeah. api.machines.dev is a public endpoint for our machines api.

EDIT: See this comment for an example on how to make the provider use the public endpoint https://github.com/fly-apps/terraform-provider-fly/issues/42...

EDIT EDIT: I pasted the wrong link, sorry about that.

We allow this now: https://community.fly.io/t/new-proxy-handler-pg-tls-postgres... :)

I do machines Devrel at Fly.io and I've got a whole lot of demos coming soon, so stay tuned :)

A lot of this is a Google search away. Here's an article from vox that is well researched: https://www.vox.com/22841191/gifted-and-talented-education-p...

I would argue the point that Stuyvesant is the "best" but I don't disagree with your point. The problem is that a lot of the money ends up in the schools with the rich kids and for a lot a lot of students and schools they never see anywhere near that type of money.

Yeah I tripped on my words there a bit. My point is that the gifted programs have what is considered the necessities of a good well rounded education anywhere in the world. The fact that only the gifted programs have that is the flaw.

Having been in public school for most of my life I can say unequivocally: yes. It is not uncommon for teachers to purchase books and classroom supplies out of pocket since there simply is not enough funding.

and their parents should be more likely to be involved financially and in PTA.

And when gifted programs become screeners of affluence then there are going to be financially involved parents in the PTA which benefits the whole school. But if all of those parents end up at the "good" schools then those schools have considerably more funding (on top of the additional funding from the DOE) to allow them to actually educate their students. It is all a self reinforcing cycle that benefits a few and disadvantages many.

Sure but the issues faced here in New York are not unique, just particularly visible due to the size. The systemically racist systems exist everywhere and I would be willing to bet money that in the majority of districts and regions where gifted programs exist will have absurdly low percentages of brown and black students. And again, that is not because brown and black students aren't as smart. The systems of this country deals them a bad hand before they even know they're playing the game in the first place.

If you single out the elimination of a specific program as a proxy for what you really want,

The problem is that in New York at least the gifted programs are the direct mechanism by which rich parents uphold the status quo of segregation. The gifted prgrams are not a proxy, they are a symptom. As I said elsewhere in this thread: we are looking for a fair allocation of resources to actually give schools the ability to meet every student where they are and to engage them wherever that is.

The fact that gifted programs would be needed at all is a failure of our public school system. Every school should have the resources to adequately engage and educate every student regardless of their academic starting point.

But the way I see it the discussion about supporting kids that are truly gifted shouldn't be dismissed

Sure! Yes! We are looking for a fair allocation of resources to actually give schools the ability to meet every student where they are and to engage them wherever that is. All teachers want to be able to meet kids where they are, wherever they are, but they don't have the resources to.

as though gifted programs take up a sizable chunk of funding rather than, you know, the schools.

I am saying that. "Gifted" programs and the schools that house them eat up a sizable chunk of funding.

Alright, I don't imagine this will be a common take here but here goes. I am a product of the New York City public school system. I have spent the majority of my life as a student in it. The New York city public school system is both the largest public school system in the country and the most segregated. The argument about removing gifted programs are built on the faulty assumptions that the students in those programs are "more gifted" than everyone else and that the work is truly more advanced. Neither of those are the case.

Gifted programs are used to advance and maintain the status-quo of segregation in our schools. The correlation between medium household (of which Black americans are at a disadvantage) and acceptance into the gifted program is much stronger than the correlation between merit and acceptance. I've spent my life in this system and I can tell you with one hundred percent confidence that the reason many if not most of my black peers don't get into these programs is not due to any lack of merit or intelligence.

Now lets look at the second assumption, that the gifted programs provide a higher level of education. This is not true. What happens is that gifted programs get significantly higher funding than other schools and so the gifted programs can afford to give a good well rounded education, which is a good thing! The problem is that so many of our schools, especially in Brown and Black neighborhoods) are completely underfunded, without enough teachers or resources. This of course perpetuates the systemic inequities that begun this cycle in the first place thus repeating the whole cycle.

When we are calling for an end to "gifted" programs in New York, it is not because we "hate smart kids" but because we want resources to be evenly divided so that everyone can get a well funded well rounded education, not just the rich kids in gifted classes. This is not a single issue but is a larger component of an attempt to dismantle segregation in public schools. It drives me crazy to no end to see smart people fall into the ideological trap of believing gifted programs are something they aren't.

I did consider tiptap/hocuspocus, but hocuspocus costs more than I can spend on a personal project right now. Additionally, the architecture of the app I am building makes heavy use of subdocuments, something that most of the yjs ecosystem doesn't support. I am likely going to end up using tiptap but swapping out the stable version of y-prosemirror it depends on with my fork that has what is needed to suport subdocuments. I really do love what the team at überdosis are doing though, I am really excited to see what kind of design choices hocuspocus makes behind the scenes, since my current server is kind of esoteric, and I'm sure they will have come up with a much better way to do it.