stabbles

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.

I was surprised to find that this sentence

> Plan prices aren’t changing

did not continue with an em-dash followed by something profound that is changing.

Plan prices aren't changing -- the value you get out of it is.

Other than TPUs they're also planning for 960,000 Rubin GPUs [1] which can do 33 teraflops fp64 each, so over 30 classical exaflops, and with emulation it could be more than 100 exaflops.

[1] https://blogs.nvidia.com/blog/google-cloud-agentic-physical-...

Another one I noticed is "or maybe I hallucinated that" instead of "or maybe I dreamed that". Researchers will be horrified to learn that even talk about LLMs affects people's vocabulary.

Oh no, LLMs threaten our individuality ⸻ what will we do?!

Are grammatical errors and typos fashionable now? Reading this post it seems the anti-thesis in the LLM era is not to edit at all, but rather write down a stream of consciousness to make it "personal".

My experience with RISC-V so far is that the chips are not much faster than QEMU emulation. In other words, it's very slow.

You're glancing over the fact that mathematics uses only one token per variable `x = ...`, whereas software engineering best practices demand an excessive number of tokens per variable for clarity.

The other day someone commented on this site that in the age of agentic coding "maintaining a fork is really not that serious of and endeavor anymore." and that's probably the case. I'm sure continuously rebasing "revert birthday field" can be fully automated.

Then the only thing remaining is convincing a critical mass that development now happens over at `Jeffrey-Sardina/systemd` on GitHub.

That's overstating things. The biggest piece of infra is PyPI, to which uv is only an interface. They do distribute Python binaries, but that's not very impressive.

You would think that Finland's unemployment rate (10%+) would influence its ranking, but that's not the case at all.

You really need dedicated types for `int64` and something like `final`. Consider:

    class Foo:
      __slots__ = ("a", "b")
      a: int
      b: float

there are multiple issues with Python that prevent optimizations:

* a user can define subtype `class my_int(int)`, so you cannot optimize the layout of `class Foo`

* the builtin `int` and `float` are big-int like numbers, so operations on them are branchy and allocating.

and the fact that Foo is mutable and that `id(foo.a)` has to produce something complicates things further.

That was how the Mojo language started. And then soon after the hype they said that being a superset of Python was no longer the goal. Probably because being a superset of Python is not a guarantee for performance either.

The TL;DR: code should be easy to audit, not easy to write for humans.

The rest is AI-fluff:

> This isn't about optimizing for humans. It's about infrastructure

> But the bottleneck was never creation. It was always verification.

> For software, the load-bearing interface isn't actually code. Code is implementation.

> It's not just the Elixir language design that's remarkable, it's the entire ecosystem.

> The 'hard' languages were never hard. They were just waiting for a mind that didn't need movies.

I wouldn't call "ChatGPT says" an equivalent of LMGTFY. The former is people in awe with the oracle, the latter is people tired of having to look something up for others.