RossBencina

Here's my technically grounded response:

As far as I understand, inspecting the compiled binaries in any way would violate clean-room principles. At a minimum you'd need (A) one set of agents documenting the behavior of the executing binaries, e.g. manipulating the UI, and reviewing documentation and training manuals, and (B) a second set of agents whose only input is the output of the first set of agents. I'm not sure whether testing the real and AI generated agent side by side with equivalent inputs would constitute clean-room, although it might be legal.

I agree that a large part of the value of a product stems from "thousands of tiny design, engineering, and product decisions." But I don't agree with your conclusion. If the goal is to replicate the behavior of an existing piece of software then all you need to do is observe the behavior and replicate it. You don't need to engineer it in the same way, or arrive at it by making the same engineering and design decisions. Of-course in the end all you have is the replica, not the engineering and design heritage, product management, or the teams to carry the work forward. But that is the same problem open source "clones" of commercial products have often suffered from.

> most devs don't want to do formal verified system development.

That may be true. Serious question though: even if most devs wanted to develop formally verified code, do you think that it is reasonable to suggest that the typical systems developer could do it with today's tools? I don't mean verified protocols (TLA+) or verified algorithms (SPIN) I mean end-to-end verified code, a-la seL4. I got the impression that this is still very specialised work. Perhaps things have advanced since I last checked.

You got me thinking about C/C++ style guides of my youth...

I think Indian Hill (C, not C++) was the first one I ever read: https://www2.cs.arizona.edu/~mccann/cstyle.html

Looks like there is an updated version (1997) here: https://www.cs.cornell.edu/people/egs/comp303/tutorials/csty...

Paul Haeberli's "The SGI C Source Compliance Requirements" is hard to forget: https://www.graficaobscura.com/ccode/index.html

I wonder whether there is a centralised historical archive of C/C++ style guides?

The modern staples are covered here, I guess:

https://github.com/kciter/awesome-style-guide#cpp

Numerical Recipes in C does that.

As far as I know Aaron never distributed that which was collected in the MIT data closet.

The first thing to note is that papers vary wildly in terms of their information density and in terms of their accessibility and relevance to you as a reader. I can easily imagine reading some papers many times because I really want to understand all the details.

That said, the depth that I read at mostly depends on why I am reading something. Most papers I don't read in depth, but whether I initially only read the abstract or skim the whole paper depends a lot on a lot of factors (paper content, length, ease of access to full text, whether I am triaging a lot of papers at once, how interested I am in the specific paper (usually based on the title and/or authors, maybe the abstract), etc.).

I read in multiple passes of increasing depth. Zeroth reading is more-or-less triage: is the paper worth reading at all? First reading would generally be start-to-finish. I underline and/or mark up the margins with particularly interesting/important sections and also star key references based on the author's commentary.

If it's an algorithm or math-heavy paper either I only care about the gist and I don't go deeper, or I dig in with further readings and study to properly understand the details. That could be relatively quick, or it could be a whole rabbit hole if I need to learn some background. Sometimes it takes a while for the importance of a paper to dawn on me, in which case I come back later and read in more depth.

With the references I generally only follow those with relevance to my research goals. For example the authors might have detailed a technique in an earlier paper, or they might have cited other relevant work that I was not aware of.

An abstract and an introduction are two different things. For me, as a reader, the main role of the abstract is to help me to decide whether to even look at the rest of the paper, let alone read it. I want to know what is in the paper that I will not find in other papers that are competing for my time. Everything should be very clear: the context, the main research contributions and/or findings, novel aspects of the approach, limitations; plus any other information that in the author's view should motivate me to read the paper. Then if I do read the paper, there should not be any surprises: the content that the abstract promised should be present and, ideally, all of the valuable content in the paper should have been advertised in the abstract.

Different fields use different standard forms or styles for abstracts. If you have not already done so you can get a feel for this by looking at a random sample of the top 100 most-cited papers in your field (or your target conferences, journals, arxiv categories) and quickly compare to top 100 in a couple of disparate fields (e.g. biochemistry, economics, anthropology, mathematics).

Of course, there are good reasons to read a paper besides the quality and content of the abstract. Consequently, there are well known papers with non-standard abstracts. I recommend mastering the basics first.

AI can make decisions all it likes. I if you don't integrate it with the drone strike MCP server it's as impotent as a JVM without any code to execute.

I can recommend "Shared Memory Synchronization," by Michael L. Scott for an introduction to nuts-and-bolts level detail.

I was expecting to see mention of Microsoft/Apple executable code-signing in the examples. I know key lengths are well beyond 1024 now, but on the Microsoft side it was (is?) possible for USB tokens to be distributed in the mail. What I don't know is whether the tokens could be used as oracles in this attack.

An operating system kernel is the last place you want an unsafe language, if you can help it.

It would be helpful if you named the falsehood for those of us following along.

TFA mentions power usage from a dollar cost perspective, but there is also the thermal aspect. You do not want to trigger thermal throttling (or lose boost) while doing almost nothing.

I'm curious about your mental model. Would it be accurate to say that the async tree is the "IO program" and the sync functions operate on pure data, or is it more complicated than that?

Here's the force pushed pyproject.toml with the new author if anyone cares:

https://github.com/google/artemis/compare/14e02c4c27bc5b3c0d...

    + authors = [
    +     { name = "somew1nd", email = "[REDACTED]@outlook.com" },
    + ]

Seems legit

Flagging because the title here on HN is editorializing. The actual page title is "I expected better from Google"

I was going to comment on the title's perpetuation of big IPs stealing/theft meme but it turns out that TFA did not use those words.

> One cannot expect a compiler to come up with such encoding.

One could, however, imagine a sufficiently expressive language that allows the developer to specify the encoding schema without resorting to raw 64-bit words.

+1. I've used this with Lattice UP5K for some experimental development. I wanted to be able to quickly skip between working on Windows and Linux. Worked well at the time.

Seems legit. My only question is whether a developer has sufficient copyright to grant such a license.

> disk heads to optimized queued reads of data in a “traveling salesman” sort of way

Luckily the read heads only have one degree of freedom, so the "elevator algorithm" is sufficient: https://en.wikipedia.org/wiki/Elevator_algorithm

The essential concepts of mathematical reasoning, if there are such things, are the concern of mathematical logicians, or maybe even psychologists, not, in general, of working mathematicians. One of my professors once told me something to the effect of "if you think you are going to learn any of that here, you are in the wrong place."

If you are interested in Terence Tao's personal mathematical inner world, he touches on that during his interview with Lex Friedman, which I think you might find interesting. Interviews with Kevin Buzzard sometimes touch on these themes too.

CBT is not a first line treatment for ADHD in Australia. Indeed standard CBT is contra-indicated because it requires the kind of "homework" that ADHDers struggle with. There are CBT variants tailored for ADHD however.

Russel Barkley is a pioneer in the field of ADHD research. I have heard of such a claim, but not from Russel Barkley. Could you provide a link of Russel Barkley making the claim please?

> It's competing with a $200/mo subscription or renting server gpu time

Not if you're an enterprise that wants or requires on-prem inference.

Daniel Lemire specialises in high-performance algorithm implementation. In recent years he has been impressed by specific performance characteristics of Apple's CPUs. For example, their ability to eek out the maximum possible throughput from a given instruction stream's data dependencies. My information may be stale, but when I read Daniel's comments I assume that Apple is being used for compariosn because it is the current leader, and take it as given that AMD and Intel are behind. You can probably find sources where he makes head-to-head comparisons with AMD and Intel. If you're not familiar with his work I can recommend it. The Wookash podcast interview is a gentle introduction, there is open source code and academic papers if that's more your thing.

I think you are correct. Clearly I am still traumatised by the cost of converting floats to ints in the x86 era.

I am probably dating myself here, but in C the default rounding mode is round-to-nearest and the cost of switching the x86 FPU to truncate (and back) in order to perform the truncation is extremely expensive. Perhaps other instruction sets have truncate-to-integer instructions that ignore the active rounding mode.

Agreed. I was opining on the psychological "getting used to" aspect, not the technical merits.

x and y are integers represented as floating point

  > d = trunc(x/y);     // floor works for unsigned
  >
  > // NOTE: if only want 'd' and it's being converted to an
  > // integer then the truncate or floor operation is
  > // free in the float to integer conversion.

Please show me how to portably truncate or floor a floating point value to an int in C for "free".

> The third I suppose I care less about, just because I've kind of become used to it

I've never become used to it. My impression is that the constant churn has accelerated. Plausible drivers are (1) normalize novelty as desirable (like fast fashion), (2) product developer/designer incentive structures that reward revolutionary change over progressive refinement. The global switch to subscription models and continuous deployment didn't help.

> more like services and less like physical tools that never change.

I'm not sure that constant change is a characteristic feature of services, especially not professional services.

It used to be that you bought a piece of software and used that version until you decided it was worth upgrading, like a particular physical tool. The software still evolved, just like the design of physical tools can, in principle, evolve.

All that said, agentic AI tooling is evolving so rapidly I'm not sure an expectation of stability is realistic.