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.
Working in an organization without a mono-repository I've actually found it extremely difficult to keep a tab on PRs and issues across multiple repositories. For a problem that should be resolved by a "For me" page that just lists out all your active incoming and outgoing PRs their multi-page solution involving search filters that often need to be reset feels extremely weak. I've worked on large multi-tenant solutions before and a page where you can "SELECT * FROM everything LIMIT 10" is the absolute last thing you want to give to users.
It is bizarre to me that so much of their tooling defaults to acting across the whole of github data points without guiding the user towards (or even making available as far as I can tell) a way to easily scope requests down outside of a complex search filter.
Hey, that's awesome and nevermind me. I just got stumbled by their UI.
There's probably a fair argument about how discoverable these are (especially given their labeling as "All Issues" and "All Pull Requests") but that tip is quite helpful to me personally. Thanks for sharing it, I really appreciate it!
There may be some magic they do to better optimize within-user-searching. It's something that they could hide in implementation details so we can't be sure unless they spill the beans but it's feasible - especially with the default search parameters they're using.
I'd still love something a bit more obvious and intuitive but if it's just a UX failure that makes me feel a lot better.
> There may be some magic they do to better optimize within-user-searching. It's something that they could hide in implementation details so we can't be sure unless they spill the beans but it's feasible - especially with the default search parameters they're using.
I would have believed this until last week when they had a little banner informing me that I might not see all the PRs but that they really were there and that I could use such-and-such API to find them myself.
If the direct API existed and was working, but the web UI wasn’t seeing the PRs, then presumably it meant that the web UI was not optimizing the default trivial search query to use the direct API.
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.
I suspect they were referring to some of the things git allows for non centralized version control. There are simplifications if you just wanted a centralized system like cvs had.
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.
I'm not convinced, though neither am I an expert. I think LLMs would use that same typo to "conclude" that it is A or B or C, depending on what it "feels like proving" at the time.
LLMs are surely excellent at style transfers, but I doubt they can reliably attribute a given style to less well-known authors.
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.
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.
It also fails to mention glibc-hwcaps, which would've been a cleaner solution in the context.
reply