codys

Prompt regurgitation. Model was likely instructed to create the app to do this piece "by hand" (or a phrase with similar interpretation) because the author wanted to avoid pulling in a dependency of some kind.

It'd be very unfortunate if Postgres didn't have regression tests for data loss due to bad io patterns. Should be possible to do some checks against those in an appropriate test harness. Which might mean "have qemu run something we can kill off and examine the results".

If those don't exist, I hope folks recognize how useful they are and add them.

Yes, I agree it would be very nice to have a way to integrate ACME into zeroserve. I'm not sure if zeroserve's plugin system might allow one to add a plugin to support it?

zeroserve doesn't use the Linux kernel's eBPF runtime to run the eBPF it uses, so the constraints of the Linux kernel's eBPF runtime (chosen because of how the Linux kernel thinks about protecting the Linux kernel from user space) don't apply to zeroserve (or other tools that use the eBPF instruction set but don't use the Linux kernel's particular implementation)

I hope this signals a departure from us being stuck without web usb in firefox too. It's a shame that I've been stuck using chrome for it.

And maybe we'll get web bluetooth too.

I think their site is just slow, potentially because more people than they are used to are trying to view it.

I was unable to load it initially (got an error from firefox) and had to re-attempt. Still slow if one forces a reload (shift-r, etc, to not use local cache).

The idea with either requiring very wide band or frequency hopping on the 900Mhz band is to make it so that usages of the 900Mhz band 1. are tolerant to some loss (ie: by temporary collision) and 2. don't collide continuously (by using wide band or frequency hopping).

It's a mechanism to try to make the 900Mhz band more useful to uncoordinated users.

The Apple way for hardware is more to design the thing so it breaks under normal use very quickly, and then refuse to replace it under warranty.

It's not a leading colon: It is a colon separator between the username and password, and the command used has the username as an empty string.

Also, the "obvious reason" that American politics sent zero ex-presidents to prison is that Biden chickened out. So, there's that.

Don't forget Ford deciding to protect his political allies (by pardoning Nixon). And George HW Bush doing similar (preventing Iran-Contra scandal investigation by pardoning participants who could have fingered Bush or Reagan)

I'm not sure I follow. This outage seems like it occurred for less than 1 day. The post you link to is about having certificates expire after 45 days. What's the connection you see?

Seems you could use a single SQL statement for that particular formulation. Something like this, using CTEs is possible, but alternately one can reformat them as subqueries. (note: not sure how the select of orders is intended to be used, so the below doesn't use it, but it does obtain it as an expression to be used)

    WITH
     o AS (
      SELECT FROM orders
      WHERE orders.id = $1
     ),
     os AS (
      SELECT FROM orderStatuses
      WHERE orderStatuses.orderId = $1
      ORDER BY DESC orderStatuses.createdAt
      LIMIT 1
     )
     INSERT INTO orderStatuses ...
     WHERE EXISTS (SELECT 1 FROM os WHERE os.code != $2)
     RETURNING ...something including the status differ check...

Garbage collection is not required for memory safety.

Languages that have garbage collection are not all memory safe.

It seems like the messenger might endorse the message though, and is attempting to be coy.

Folks should be careful of people using the "messenger" title to attempt to obtain the appearance of impartiality.

So no one that actually has to renew these certificates.

I believe google, who maintain chrome and are on the CAB, are an entity well known for hosting various websites (iirc, it's their primary source of income), and those websites do use https

OpenBSD does start X. And subsequently OpenBSD apparently hangs (or did so previously) when OpenBSD was running under Qemu.

The subject in the parent comment changed to OpenBSD when they mentioned it, and it appears you may have overlooked the subject change.

Possibly a better comparison (though a bit dated now) would be AT&T (or whatever telephone monopoly one had/has in their locality) charging an additional fee to use a telephone that isn't sold/rented to them by AT&T.

I am assuming the message durability guarantees lean towards YOLO rather than ACID?

"Core" nats doesn't have durability. Nats jetstream is the api built on top of nats that in the main nats-server impl provides durability. Jepsen tested Nats Jetstream.

Also from your link:

Regular NATS streams offer only best-effort delivery, but a subsystem, called JetStream, guarantees messages are delivered at least once.

The project linked here does not implement the nats jetstream api, just normal nats.

So yes, it seems its same (documented, understood) "yolo" as normal nats.

It seems it's just a part of a doc on style in tigerbeatle, in a similar way to the various "Google Style Guide" for code. These rarely have something new, but document what a particular project or organization does with respect to code style.

You've linked to a bug that was unintentional and was fixed.

Go allowing torn writes for their slices and interfaces (their fat pointer types) is intentional behavior in the go implementation and has no sign of being fixed.

Some one getting unsafe code unintentionally wrong is not an indication that any language lacks memory safety.

Here's an example where a bug could exist in go due torn writes in a real program.

I found this by searching for places where folks reload there config at runtime, as they are generally a place where people forget to synchronize correctly in go.

1. A viper.OnConfigChange callback is set up to call readConfig(): https://github.com/OdyseeTeam/chainquery/blob/48c092515dea5c...

2. Inside readConfig(), we assign to a slice `twillio.RecipientList` (https://github.com/OdyseeTeam/chainquery/blob/48c092515dea5c...

3. Note that in Go, slices are objects composed of 3 words (https://go.dev/blog/slices-intro#slice-internals) And there isn't syncronization built-in over updating them. As a result, if something reads the slice while it's being updated we will mix together a data pointer & length & capacity that correspond to different real slice objects. If the length we read is from a slice that has real length 10, but the data pointer we read is from a slice with real length 1, when iterating we'll read memory out of bounds.

4. in the context of this particular program, we may send SMSs to recipients who were never in the configured list if a config change occurs at the right time. Or a segfault. Entirely unclear if reading the memory will result in reasonable behavior.

Note: I'm not familiar with this repo otherwise. This is from a quick search.

In that case, I can just refer back to my original comment: https://news.ycombinator.com/item?id=46388948

And then note that memorysafety.org says this (in case folks haven't read it):

Memory safety is a property of some programming languages that prevents programmers from introducing certain types of bugs related to how memory is used.

They then provide an examine of out-of-bounds read/write. Which is the exact example I noted in my linked comment.

(Note: memorysafety.org does not provide a concrete definition of memory safety, but we get enough from what it says in this case)

The site does not require the known existence of an exploit in popular software (and does not require that _any_ exploit be possible, a bug is sufficient), merely that the language fails to block "certain types of bugs".

"at the moment" implies that Go would need to change for that statement to change, but instead we're waiting on a programer to make a mistake (A mistake that memory safe languages prevent).

Which does get us to why defining the properties of a language based on what people have written in that language _so far_ is weird. It's not really a property of the language that no one has screwed up yet. It's perhaps an indication that it might be less likely that folks will screw up, which is where the "probabilistic" comes in. It assumes that given the lack of a counter example (a screw up) so far, and given the time that Go has existed, it _appears_ that it's low-likelyhood to screw up go programs in that particular way.

Agreed that the word is non-targeted in one way, but it's better than the alternate (implying go would have to change to become memory unsafe), if one wants to talk about how-memory-safe-is-go.

Interesting interpretation of that phrase. I think saying "probabilistically memory safe" would be more accurate (and more clearly communicate that idea), because we're betting on when a known case of memory unsafety in the language will show up in some piece of software.

It sounds like you have a definition of memory safety you aren't disclosing.

Please fully provide your definition of memory safety. Not interested in trying to figure out what it is in a 20-questions-over-hn way.

One can evaluate Go using the extent of the definition from the site itself, which uses out of bounds reads and writes as a sign of memory unsafety.

Go's implementation allows torn writes for interfaces (which are 2 words in size). These torn writes allow arbitrary memory reads/writes (a superset of out of bounds reads/writes)

Go can have memory unsafety leading to arbitrary memory reads and writes by having an interface replaced by another thread (go interfaces use 2 words, one for the vtable and another for the data. It does not replace these in a thread safe way, so one can use a vtable to work with an unexpected data pointer.

Folks have shown this allows the kinds of arbitrary memory reads/writes that folks normally ban in their definition of memory safe (and this post's website has a definition does as well):

https://research.swtch.com/gorace

https://blog.stalkr.net/2015/04/golang-data-races-to-break-m...

https://www.ralfj.de/blog/2025/07/24/memory-safety.html

This site is curious in that in incorrectly categorizes go as memory safe.

Perhaps in part because the sponsors are invested in using go and benefit from its inclusion in a list of memory safe languages.

The chart does not describe speed (either in general or in any particular case). Speed/performance/latency is a thing users care about that is not included in the feature list.

Ya, UUID v7 has been standard for a few years now. Perhaps the author is not familiar with the terminology of RFCs and so is misinterpreting the terminology used by IETF: "Request for Comments" and "Proposed Standard" can sound like they're not complete to folks not familiar with the IETF's process. Even then though, I would think they'd notice all the software that has UUID v7 support.