Some agents use sandbox-exec, some agents don't, some agents that do use it have bugs configuring & executing sandbox-exec.
This may also have bugs but having a single setup for your sandbox reduces the surface area & frankly I have significantly more trust in literally any individual dev creating a free generic open-source tool than I do in a company selling frontier models as a service & vibe-coding[0] an afterthought companion cli at 80k loc/mo.
Other angles of critique & consideration already covered well by sibling commenters. One extra consideration (unrelated to streams, more general) is the API design & dev UX/DX:
type Stream<T> = {
next(): { done, value: T } | Promise<{ done, value: T }>
}
the above can effectively be discussed as a combination of the following:
type Stream<T> = {
next(): { done, value: T }
}
type Stream<T> = {
next(): Promise<{ done, value: T }>
}
You've covered the justifications for the 2nd signature, but it's a messy API. Specifically:
> My way, if I define a sync transform over a sync input, the whole iteration can be sync making it possible to get and use the result in sync functions. This is huge as otherwise you have to write all the code twice: once with sync iterator and for loops and once with async iterators and for await loops.
Writing all the code twice is cleaner in every implementation scenario I can envisage. It's very rare I want generalised flexibility on an API call - that leads to a lot of confusion & ambiguity when reading/reviewing code, & also when adding to/editing code. Any repetitiveness in handling both use-cases (separately) can easily be handled with well thought-out composition.
How is it cleaner? I used to actually do that. I wrote everything twice. I even built fancy tools to help me write everything twice.
But the bigger problem here is that sync and async aren't enough. You almost need to write everything three times: sync, async, and async-batched. And that async-batched code is gonna be gnarly and different from the other two copies and writing it in the first place and keeping it in sync is gonna give you headaches.
To see how it played out for me take a look at the difference between:
Seems like it's only when adding 1 + 4, 6, or 8 in a place value or where one of them is 0. It doesn't seem like it'd ever hold across a carry, but I could be missing something.
Edit: There's actually a few cases with adding 2 as well!
I would posit then that this article simply doesn't apply to you at all. The feature being described is targetted at users who are effectively developing their own schemes (albeit in a rather simplified automated manner). If I'm taking something off the shelf, I'm using the appropriate recommended base16. I have no expectation that a wild base16 is going to align with any 3rd-party's curated scheme.
I do understand that this logic isn't always going to click with people given the differing contexts of a terminal-wide -vs- app-specific (i.e. vim) approach, but again: that disparity seems either a legacy issue (caused by things like this 16-256 mis-alignment) OR simply a philosophical difference (whereby people who customise at the term level shouldn't at the app level & vice-versa).
Gentoo's wiki is still great (& Arch's has been great for a long time), but yes, Arch's is probably improving at a faster rate. Arch is also a little more comprehensive when it comes to mainstream tech that's divergent like init & network management - Gentoo's still good here but openrc & netifrc show their influence throughout.
I think the Gentoo wiki that gp is referring to is the old gentoo-wiki.info that went down after a hardware failure or something like that and never came back.
The wiki.gentoo.org we have now restores some of that but probably not everything - and there was a void left between them that let the Arch wiki gain mindshare.
This is timely news for me - I was just standing up some Loki infrastructure yesterday & following Grafana's own guides on object storage (they recommend minio for non-cloud setups). I wasn't previously experienced with minio & would have completely missed the maintenance status if it wasn't for Checkov nagging me about using latest tags for images & having to go searching for release versions.
Sofar I've switched to Rustfs which seems like a very nice project, though <24hrs is hardly an evaluation period.
Why do you need non-trivial dependency on the object storage for the database for logs in the first place?
Object storage has advantages over regular block storage if it is managed by cloud, and if it has a proven record on durability, availability and "infinite" storage space at low costs, such as S3 at Amazon or GCS at Google.
Object storage has zero advantages over regular block storage if you run it on yourself:
- It doesn't provide "infinite" storage space - you need to regularly monitor and manually add new physical storage to the object storage.
- It doesn't provide high durability and availability. It has lower availability comparing to a regular locally attached block storage because of the complicated coordination of the object storage state between storage nodes over network. It usually has lower durability than the object storage provided by cloud hosting. If some data is corrupted or lost on the underlying hardware storage, there are low chances it is properly and automatically recovered by DIY object storage.
- It is more expensive because of higher overhead (and, probably, half-baked replication) comparing to locally attached block storage.
- It is slower than locally attached block storage because of much higher network latency compared to the latency when accessing local storage. The latency difference is 1000x - 100ms at object storage vs 0.1ms at local block storage.
- It is much harder to configure, operate and troubleshoot than block storage.
So I'd recommend taking a look at other databases for logs, which do not require object storage for large-scale production setups. For example, VictoriaLogs. It scales to hundreds of terabytes of logs on a single node, and it can scale to petabytes of logs in cluster mode. Both modes are open source and free to use.
Disclaimer: I'm the core developer of VictoriaLogs.
> Object storage has zero advantages over regular block storage if you run it on yourself
Worth adding, this depends on what's using your block storage / object storage. For Loki specifically, there are known edge-cases with large object counts on block storage (this isn't related to object size or disk space) - this obviously isn't something I've encountered & I probably never will, but they are documented.
For an application I had written myself, I can see clearly that block storage is going to trump object storage for all self-hosted usecases, but for 3P software I'm merely administering, I have less control over its quirks & those pros -vs- cons are much less clear cut.
Initially I was just following recommendations blindly - I've never run Loki off-cloud before so my typical approach to learning a system would be to start with defaults & tweak/add/remove components as I learn it. Grafana's docs use object storage everywhere, so it's a lot easier with you're aligned, you can rely more heavily on config parity.
While I try to avoid complexity, idiomatic approaches have their advantages; it's always a trade-off.
That said my first instinct when I saw minio's status was to use filestorage but the rustfs setup has been pretty painless sofar. I might still remove it, we'll see.
> Your either don't understand or don't want to understand what people are commenting about here.
From reading your comment I think this observation applies to your own understanding, not the gp's.
> whether the value of the money paid by tax payers to artists, equals the value of what they give to the tax payers in return. [...] one might wonder why they apparently are not able to sell their art for the same amount of money.
You might not see it but this is effectively equivalent to thinking only money has value, because you're describing a system whereby value is defined by money. Your dichotomy assumes anything that cannot be sold has no value, & anything that is sold is only as valuable as its price. The emergent conclusion from that formula is that only money has value.
It's worth noting that it also follows from this that value is defined by people with purchasing power. If for example the only cohort who value any given piece of art cannot afford to financially support the artist creating said art, not only is the art & the artist's work without value, but by extension so too are the perspectives, autonomy & - ultimately - the lives of that cohort without value.
You’re making a logical leap, how can you say only money has value when things are worth money? That item has value equivalent to the money given for it, therefore that item has value. It’s likely you’d be able to find people who are willing to trade some electronic device you have for another equivalent one (some iPhone for some Android) without exchanging any money. Money is just the measure of value, it’s like saying something cannot be 5ft tall without the existence of a measuring tape. Societies have existed before money they were just inefficient.
> That item has value equivalent to the money given for it, therefore that item has value.
> Money is just the measure of value
Money is the measure of market value. If you believe it's the measure if inherent value, you believe anything outside of the market has no value. E.g. that human lives have no value outside of waged labour (or heck, even slavery).
The point here is the monetary value is a model of value, not the definition of it. If you are defining an item's value by it's market price, then you believe what the gp was describing: that "only money has value" (since it defines all value).
Sure, but my point is that 450m requests is just not a lot. Humans are bad at big numbers, and this number sounds like a scary amount of traffic, my point is that it is a very boring amount of traffic even on modest hardware.
I personally wouldn't stick it on a single VPS because we can do way better than that in terms of reliability, but the point stands that you don't need very much in terms of resources to serve this.
ML has come a long way but I have yet to encounter anything that does this reliably with speech, never mind song lyrics.
> works with any song on your computer
I'd be shocked if this is true.