stabbles

Imagine this: OpenAI runs their benchmarks of unreleased models on systems physically disconnected from the internet.

To be fair, many shells have command caching, so they effectively roll their own exec syscall wrapper:

    $ python3 -c 'print("hi")'
    hi
    $ hash
    hits command
       1 /usr/bin/python3

Indeed, it's a libc construct.

Nice, PT_INTERP is the only non-relocatable thing of ELF files and typically requires wrapper scripts/executables.

Regarding shebangs, I've never understood why the kernel cannot resolve e.g. `#!sh` relative to PATH instead of CWD. Posix prescribes that you should look for `sh` in PATH and don't expect it to be in `/bin/sh`. And using `/usr/bin/env sh` has the same issue: what if coreutils is installed elsewhere.

Not really, a theorem with a hard proof can have simple but important corollaries. It's also not unthinkable that theorems exist with proofs that cannot reduce to something simple/short.

Banana Paper was on the shortlist

If you take a frame you see it's neither random nor dots:

https://i.imgur.com/CgtyGjl.png

From a single frame you can definitely identify boundaries because the dots are sliding and get truncated.

So the image model's benchmark is to generate an image with the corresponding SVG sources.

Nix hashes the build inputs, for which deterministic builds are not required, only desirable.

Speeding up C/C++ compiler bootstrapping, starting at a single binary of <1KB. Currently it gets to GCC 4.7 in 2-3 minutes on x86_64 and aarch64: https://github.com/haampie/shpack

This begs for a modern version of https://csszengarden.com/, where the CSS is generated by different LLMs and prompts.

Isn't that covered by O_CLOEXEC?

A medicine for those who anthropomorphize LLMs is to run the LLMs deterministically (without randomness and memory files).

It feels very unnatural to get the same conversation verbatim at a different point in time.

David Hume pointed this out in 1740, and his advise still applies:

    A reason should be given, for what seems altogether inconceivable, how this new relation can be a deduction from others, which are entirely different from it. But as authors do not commonly use this precaution, I shall presume to recommend it to the readers.

I think this is fair criticism. It's hard to read this blog cause its premise is based on an "appeal to nature" fallacy.

The Dutch version of this is to wave at the cheek.

Is one day enough to find vulnerabilities? Who keeps an eye on new releases? Otherwise the problem continues to exist, just delayed by one day.

Isn't it mostly the medium that's problematic? With an issue tracker it's easier to close as duplicate

Isn't that rather difficult given the `.tar.gz` layers?

You can look at a histogram of number of words per sentence, and you'll find immediately that it's written by an AI.

    When?
    Today.
    Minutes.
    Four years.
    $54 million.
    Collect feedback.
    Delivered faster.
    Not days.
    Not weeks.
    It's free.
    ...
    No $19 million in upfront costs.
    They're now doing meaningful work.
    Let me put that in context.
    That's a 95% cost reduction.
    But think about what that represents.
    And we can show you how.

This comment is misinformed. Non-deterministic builds would also result in one tarball redistributed to all distro users. The ROP exploits don't work because of ASLR.

Yeah, that suggestion made me roll my eyes. It's the wrong granularity, there's no build system support, it's inconvenient (executable wrappers? require the user to understand all transitive deps?).

It also fails to mention glibc-hwcaps, which would've been a cleaner solution in the context.

I noticed the same https://news.ycombinator.com/item?id=47940213. My working hypothesis is that, given that a filter was always required (prs and issues are likely rows in the same database with a bool property to distinguish them), someone thought it'd be good to use the search API uniformly. But search is on the derivative of the underlying data, in contrast to the specific APIs for listing issues and prs.

What are you referring to when you say it's "fundamentally computationally inefficient"? It's pretty efficient because it's content-addressed, plus optimizations to reduce storage and data transfer with packfiles.

If chess is solved and white wins, black is always in Zugzwang. We might not know.

It's not necessarily an illusion. If chess is solved and it turns out white wins with perfect play, black's first move is zugzwang.

This made me double check if it wasn't someone's vibe code scam website.

Sure, in the days of Markov chains you could already generate nonsense in the style of Shakespeare, so it shouldn't be surprising you could also do the inverse.

But the LLM will trigger on a typo you've made only once, and argue "that's a typical mistake for an Italian" and use those clues. It has a much better prior to make informed decisions.

After yesterday's outage they admitted that their elasticsearch index for issues/prs lost data.

They seem to have changed the primary source of data in the issues and pull requests tabs (w/o filters applied) from the underlying database to the elasticsearch search index, which has the side effect that there's a noticeable delay between state change of an issue/pr and an update in the UI. But as seen today, these can get out of sync, and apparently they even had data loss in the index.

I would really like to know their reasoning for making that change. I can totally imagine that they wanted to "simplify" so the UI uses only a single data source instead of two.

As a user it's incredibly annoying to have a delay between issue/pr state changes and the search index picking it up.

Is "migration to azure" or "microsoft acquisition" a cause or a symptom?

I'm wondering to what extent the natural life cycle of SaaS products comes down to: the company grows, the old guard with good technical taste move on, bad technical decisions are made, quality declines, users move on.