HN user

thesmart

9 karma
Posts0
Comments29
View on HN
No posts found.

Considering Github seems to have <99% uptime, I'm not super excited to use `gh` for anything. Besides, wasn't able to publish my skill anyway:

gh skill publish shellcraft

X shellcraft: name "shellcraft" does not match directory name "."

Can we please demand that Github provide mirror APIs to competitors? We're just asking for an extinction-level event. "Oops, our AI deleted the world's open source."

Any public source code hosting service should be able to subscribe to public repo changes. It belongs to the authors, not to Microsoft.

It's really pathetic for however many trillions MSFT is valued.

If we had a government worth anything, they ought to pass a law that other competitors be provided mirror APIs so that the entire world isn't shut off from source code for a day. We're just asking for a world wide disaster.

Saying there are cases where full scan is better than an index is really just describing an edge case where the default index implementation is non-optimal.

There are edge cases where default implementation of an index will not result in good performance in some use cases. For example, write heavy loads where the updated tuple values are frequently changing position in the index constantly. However, the solution is rarely "no index".

A solution is to throttle the index update by an acceptable delta through a non-default implementation.

A solution is to develop your own application-side index.

A solution is a custom PSQL function that interacts with an index in a more complicated way.

Maybe a non-default implementation is not priority right now, e.g. if scale is low. But it is always good to think ahead and to have a plan and to log the tech debt and track it responsibly so there are no surprises later. Don't build on shifty foundations.

It seems incredibly misguided to plug an IP address into hosts from a forum post. Is there an official source from GitHub?

And the lack of repo ratings or author reputation. How is it that I can see 2,000 reviews about a taco stand down the street but I can't easily assess deps quality in a source base I depend on for my livelihood?

I think the convenience of GitHub and NPM are good features, and it's easy to blame ease-of-use as a culprit. I have often pondered about how remarkably poor these tools are at representing repo quality. I think there are some basic questions to ask before accepting any unknown source in as a module. What is the core problem and requirements the source addresses? Does it verify the solution and how? What is the reputation of the core contributors? Is it used by any serious institutions? (Aside: download count and star count are a measure of herd mentality) What are the open issues? What are the closed "won't fix" issues? How often are issues regressed? What is a safe version? How is the versioning managed and how should I pin it? How many dependencies do I assume from this library? How severable are the dependencies?

It would be useful if package management tools facilitated the process of understanding the liability imposed by a package, but the opposite is encouraged. Authors too often put up shiny marketing materials and make bold statements about the utility and vision of their software. It would be refreshing if authors were as open about the flaws, trade-offs, alternatives, etc. but few are.

Perhaps some kind of rating or feedback system that is qualitative in nature would help mitigate the salesmanship? I'd love to know who has been burned by a project and anecdotes about how packages are used by others. Ratings around issue resolutions would also be helpful, how often have we all had major bugs dismissively closed by maintainers?

TL;DR there are ways to develop a comprehensive assessment of a repo, but our tools are lacking and need much improvement in this regard.

Does Nchan broadcast messages that may have been missed by a client that was temporarily offline? When web client's navigate from page-to-page or enter sleep mode, client's will miss messages during the offline delta. Ideally, there would be a way to "catch-up" a client or to tell if a client is permanently out-of-sync because it is beyond a message history window.