codys

github does support sha-256 repos in some kind of private beta. https://github.com/bk2204/talk-rust-in-git is one of them.

but yes: that ui in the article is likely entirely imaginary, but it's likely an option (either in the ui for private beta users or by raising a support ticket or by some internal tool) to get sha256 repos today.

The goose language has dynamic allocation via builtin types, like most systems for the past 40 years (Folks were using dynamic allocation on systems back when 640k was a lot of memory). Most embedded systems these days far exceed the capabilities of 40 year old desk top computers and also use extensive dynamic allocation.

The distinction for goose is that it has fixed locations where the free must occur (function return, effectively), not that it doesn't have dynamic allocation (because it does have dynamic allocation)

It appears they got around that by making expanding and contracting data arrays builtin types the compiler impls. And it does this by creating what they call a "data stack" for each thing that needs to grow. To me it reads like "we have a builtin type that hides the heap allocation and does the free at the scope exit ", which is fine I guess as it keeps the nature of the language in tying lifetimes strictly to function scopes.

If your system has a way to take consistent snapshots in the filesystem (btrfs, zfs) or volume manager (lvm2, perhaps with a bit of filesystem support to obtain fs consistency), that can be used to avoid database downtime, if desired.

https://www.postgresql.org/docs/current/backup-file.html

Despite all the fancy language, its more about aligning the AI behavior with the corporation's interests.

ie: the corporation wants the AI to behave a certain way for various reasons: to make it easier for them to avoid regulation, to make the corporation more money via different tiers of AI offerings, to ensure that the corporations products are hard for competitors to use, etc. And those are just the easy ones.

Every product is shaped this way. AI is not different.

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...

Does something like this work with postgres's default behavior?

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.