HN user

cbarrick

1,050 karma

SRE at Google / Prolog Fan

https://cbarrick.dev

Posts1
Comments266
View on HN

The Turis Omnia runs a derivative of OpenWrt. They provide a custom UI with an option to switch to LuCI. It's easy to flash it to upstream OpenWRT, which is what I do.

The journal regularly includes commentaries and editorials on political and economic topics [1][2]. Political talks regularly occur at the conference [3].

In fact, the trigger to all of this was a scheduled talk by Jay Bhattacharya, Director of the NIH and a controversial political figure.

It seems silly to imply that politics are to be excluded from the conference at all costs when the ADA regularly invites political speakers to that same conference.

Do you believe that handing out copies of this editorial constituted inappropriate behavior? If so, why?

[1] https://diabetesjournals.org/care/article/49/1/5/163166/The-... [2]: https://diabetesjournals.org/care/article/48/8/1309/162954/T... [3]: https://diabetesjournals.org/care/pages/2025_ada_diabetes_ca...

So you're concerned about my use of the word "paper." That's fair I guess.

But the editorial in question was in fact published in a peer-reviewed scientific journal.

Just so that we're all clear on the facts:

- The editorial was published in Diabetes Care, Volume 49, Issue 6. [1]

- Diabetes Care is a publication of the American Diabetes Association (ADA). It is a peer-reviewed scientific journal with an IF of 16. [2]

- The paper being distributed was an editorial, not research. [3]

- Steven Kahn, first author of the editorial and one of those thrown out of the conference, is the editor-in-chief of Diabetes Care. [4]

- The conference in question was The American Diabetes Association’s Scientific Sessions. [5]

The important question: Should the distribution of an editorial published in an ADA journal be considered a code of conduct violation at the ADA conference?

[1] https://diabetesjournals.org/care/issue/49/6 [2]: https://en.wikipedia.org/wiki/Diabetes_Care [3]: https://diabetesjournals.org/care/article/49/6/901/164764/Mi... [4]: https://diabetesjournals.org/care/pages/Editorial_Board [5]: https://professional.diabetes.org/scientific-sessions

The editor-in-chief of a journal handing out a paper that was published in that journal at a conference for that journal... is quite different from ranting about space lizards in a public square.

Your argument is a strawman: you are refuting an argument different from the one actually under discussion. The argument isn't "is protesting at a conference acceptable?" The argument is "does this behavior constitute an unacceptable protest?"

www.metalevel.at is run by Prolog legend Markus Triska, author of CLP(FD)/CLP(Z).

So it's not that they "discovered" anything about Prolog; they already knew the language inside out.

This article explains how to appropriately use Prolog declaratively and with full generality.

I say it's the "standard" because all new public APIs must conform to the latest AIPs.

But yes, Google has plenty of legacy APIs. And yes, GCE in particular is a HUGE pain.

Google has a similar clause in their employee contracts. I assume most tech companies do.

That doesn't mean it is enforceable, though.

Well, it depends on the language.

In Javascript, promises are eager and start executing immediately. They return control back to the caller when they need to wait. So in practice, all of your promises are running concurrently as soon as you create them.

In Rust, futures are lazy don't start executing until they are awaited. You have to use various features of your chosen runtime to run multiple futures concurrently (functions like `spawn` or `select`). But that interface isn't standardized and leads to the the ecosystem fragmentation issue discussed in the article. There was an attempt to standardize the interface in the `futures` crate, but none of the major runtimes actually implement the interface.

IIUC, this crate has similar restrictions to the std Mutex. So it depends on what you mean by "work with async code."

First, lock acquisition seems to be a blocking method. And I don't see a `try_lock` method, so the naive pattern of spinning on `try_lock` and yielding on failure won't work. It'll still work in an async function, you'll just block the executor if the lock is contested and be sad.

Second, the key and guard types are not Send, otherwise it would be possible to send a key of a lower level to a thread that has already acquired a lock of a higher level, allowing deadlocks. (Or to pass a mutex guard of a higher level to a thread that has a key of a lower level.)

Therefore, holding a lock or a key across an await point makes your Future not Send.

Technically, this is fine. Nothing about Rust async in general requires that your Futures are Send. But in practice, most of the popular async runtimes require this. So if you want to use this with Tokio, for example, then you have to design your system to not hold locks or keys across await points.

This first restriction seems like it could be improved with the addition of an `AsyncLockable` trait. But the second restriction seems to me to be fundamental to the design.

Yeah, it's a pretty versatile phrase that's hard to explain. But it does often have a connotation of childishness or naivety, even when used sincerely.

It is often used an expression of thanks or appreciation, but I associate that more with an elder speaking to someone younger.

Most of the time, it is an genuine expression of true empathy, but it's not uncommon to be used as a passive aggressive expression of false empathy. It's that childish connotation that give it the extra bite when used passive aggressively.

And that plausible deniability, where the phrase is used in a genuine context often enough that sometimes you can't tell that someone is throwing shade, is very much a reflection of southern culture.

Source: Grew up in Georgia and North Carolina, with some family in Alabama.

Defining BE integer data types seems like a bad approach.

I wouldn't want to maintain those types. The maintainer would either have to implement all of the arithmetic operations or assume that your users would try to hack their way to arithmetic. But really, you shouldn't ever do arithmetic with non-native endianness anyway.

Instead, define all your interfaces to work with native endianness integers and just do byte swapping at the serialization boundaries.

Ball Pit 4 months ago

Doesn't appear to put much strain on my Pixel 10!

Graphics and physics performance in 2026 across all kinds of hardware is wildly impressive.

Exactly. No need to engineer an allocator. You only live once!

    void* malloc(size_t size) {
        void *ptr = mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_ANON, -1, 0);
        return (ptr == MAP_FAILED) ? NULL : ptr;
    }

    void free(void *ptr) { /* YOLO */ }
/s

There are definitely some warning signs that OP could be a bot:

- They "no longer use Github" but their Github account was only created on March 1st.

- Their blog domain was registered on March 1st according to whois.

- They have sixteen (!!) blog posts dated March 10th.

- This is the kind of project you could vibe code: "read the ffmpeg manual and convert all of its flags into a TUI." No shade on the value of the project, just that it's a good one for LLMs.

Gentoo on Codeberg 5 months ago

I was familiar with the Gerrit workflow, but not the AGit workflow.

The original AGit blog post is no longer available, but it is archived: https://web.archive.org/web/20260114065059/https://git-repo....

From there, I found a dedicated Git subcommand for this workflow: https://github.com/alibaba/git-repo-go

I really like what I've read about AGit as a slightly improved version of the Gerrit workflow. In particular, I like that you can just use a self-defined session ID rather than relying on a commit hook to generate a Gerrit ChangeId. I would love to see Gerrit support this session token in place of ChangeIds.

Quite an unhinged take.

The claim that malware "makes a ton of money" for Apple definitely needs a citation. I certainly don't believe it.

Obviously, Apple understands that the reputational damage from malware is more costly than any cut they might get from the miniscule sales of it. Apple might be evil (for some definition of "evil"), but they're not dumb.

Occam's Razor and Halon's Razor are aligned here. Apple would prefer this app not exist, but somehow it slipped through the review.

It's not though.

I thought it was, and posted this same comment on the other telnet article. But I was informed that it is back! And I was able to confirm it myself.

I don't have a telnet client on my Mac, but I was able to confirm with nc.

    nc towel.blinkenlights.nl 23

Do you want the control systems of the subway to get modified by a malicious actor? What about damn releases? Heat pumps in apartment buildings? Robotaxis? Payroll systems? Banks?

Amutability is a huge security feature, with tons of real world applications for good.

The fact that mega corps can abuse consumers is a separate issue. We should solve that with regulation. Don't forsake all the good that this tech can do just because Asus or Google want to infringe on your software freedoms. Frankly, these mega corps are going to infringe on your rights regardlessly, whether or not Amutable exists as a business.

Don't throw the baby out with the bath water.