brasic

You're quite right -- the author of that code *was* very new to the language when he wrote this, but then again, so were we all. [0]

[0] https://github.com/ruby/ruby/commit/3db12e8b236ac8f88db8eb46...

I work at GitHub. This is not new, and I promise it’s not a dark pattern.

As a sibling comment noted, someone with sufficient permissions in this repo used the “minimize” function on these comments. This is normally intended for disruptive or off-topic messages, but ultimately it’s up to the owners of the repository how they make use of our moderation tools.

https://docs.github.com/en/communities/moderating-comments-a...

Before I worked here I had no idea how much GitHub invests in platform health. It’s nearly invisible to most users but just like every other part of the internet that draws eyeballs we are under an enormous flood of spam at all times.

IMO It’s a testament to how well the system works that many years after this functionality was introduced this is the first time you encountered it.

Making a substantive point using humor != trolling.

What form of grid/utility energy storage do you expect will dominate in 20 years?

I provided a reference to back up my assertion. Do you have any?

  > Storage cost is falling even faster than generation,

Citation please. The high demand for EVs and other battery-hungry devices has led to a situation where grid scale energy storage costs are currently increasing year over year and expected to continue doing so [1]. And pumped hydro storage is not something that will flexible enough for general deployment.

  > and there are zero physics problems to be solved,
  > just practical civil engineering.

Alchemy is not a solved problem, and there is only so much lithium to go around.

[1] https://cleanenergynews.ihsmarkit.com/research-analysis/grid...

At the risk of belaboring my point, even if what you say is true this attitude is a root cause of this unfortunate situation.

Good journalism isn’t fungible — it costs money to produce. When we actively choose to not pay for media, we have no one but ourselves to blame for the awful biased or clickbait junk that results.

An aside: On https://scotrail.datasette.io/scotrail/random_apology I see heavy use of:

    order by random() limit 1

I understand that in more or less all databases this is quite inefficient: it runs `random()` for all rows, sorts those random values and then chooses the row corresponding to the first one. In tables with millions of values this could be rather expensive.

Is there any generic way in SQL to cheaply choose an arbitrary row from a collection in a way that is not deterministic? [1] I’m thinking about something that has the same characteristics as Ruby’s `Array#sample`.

Postgres has TABLESAMPLE but that only works across an entire table so it’s not flexible enough to be useful in real world situations (ie where the collection to choose a random element from is already filtered by WHERE)

Or are there any databases that know how to recognize this `order by random()` idiom and skip the extra work? Kind of like how `count(*)` usually has optimized semantics to not actually look at the distinct values of each row.

[1] I realize that SELECT without an order clause is technically arbitrary but in practice it’s usually pretty deterministic.

Why is it ironic?

One reason all these services are introducing ads is consumers’ learned unwillingness to bear the full costs of the services they enjoy.

I might argue that the true irony is grumbling about a news provider very reasonably limiting their product to those who have paid them.

Read the primary source:

https://www.michaelhorowitz.com/VPNs.on.iOS.are.scam.php

This includes WiFi as well.

A fun thing is that the full gitrevisions syntax used by `rev-parse` is supported many places on GitHub where you would normally put an object id or ref name.

For example, https://github.com/git/git/tree/master@{5.years.ago}

Note that this uses the reflog which means that it won’t work in some situations (branch renames, entries rolled off the end of the log, etc)

Hi, I work on the PRs team. Happy to answer any questions about this change!

This was posted in the changelog section of our blog, where posts aren’t attributed.

Our roadmap, including PR improvements and features is here: https://github.com/orgs/github/projects/4247/views/1

To add some nuance to the sibling reply, the SEC has extensively laid out its legal argument for why many (not all) of the coins traded on crypto exchanges are securities under US law, including specific examples. See the recent insider trading complaint [1] and this analysis [2]. Dealing in unregistered securities is a crime [3], so if the analysis is correct then the exchanges are breaking US law.

[1] https://www.sec.gov/litigation/complaints/2022/comp-pr2022-1... (¶ 95 - ¶ 206)

[2] https://www.sec.gov/corpfin/framework-investment-contract-an...

[3] https://www.law.cornell.edu/uscode/text/15/78l

I thought that AWS availability zones were intentionally not canonically named to prevent everyone from adding stuff to AZ “A”. So my us-east-1 zone “A” might be your “B”.

But that system breaks down here when you need to know whether you are in an affected zone. Is there a way to map an account’s AZ name to the canonical one which apparently exists?

This is shipped for github.com! See https://github.com/github/docs/commit/37df8eadb1f3bd0c260653... which is now live on https://docs.github.com/en/search-github/searching-on-github...

That’s very interesting! I use a very simple shell script plus git rerere [1] to keep PR stacks up to date with the bottom element’s base branch.

[1] https://git-scm.com/docs/git-rerere

Chrome has a native reader mode as well, it’s just feature flagged off for some reason:

https://knowtechie.com/how-to-enable-google-chrome-reader-mo...

For anyone watching this thread, shoot me a DM if you’d like to test this change. It should be enabled in all repos within a week or two.

Definitely! In ruby it’s even easier for most gems where source == build

Definitely. See Lady Bird Lake or Lake Travis in Austin: basically just parts of the Colorado River.

Thanks!

This is such great news for ruby. Here’s hoping with these resources rubygems and bundler can add improved support for signature verification. Rubygems supports gem signing but without a good scheme for trust, key rotation, etc it is not particularly usable. Sprucing this aspect of the ecosystem up would go a long way towards allowing ruby to maintain its historical role at the vanguard of language specific package management.

Another thing I would love to see is the ability to incorporate a signed attestation that a gem was built from a given signed commit. A common dirty trick by supply-chain blackhats is to publish a gem which contains code other than that of the corresponding tag in source control. Given that rubygems has no means to browse package contents other than downloading and extracting the tarballs for manual inspection this means that people typically reference changelog or diff links on source control hosts, despite the fact that those diffs will only be accurate for gems published by good-faith actors following platform norms.

There are a number of ways to fix this and I sure hope one of them gets implemented.

I checked and you're right: The endpoint that returns the file list has a hardcoded set of excludes and pays no attention to `.gitattributes`.

I think it's reasonable to respect the linguist overrides here so I'll open a PR to remove entries from the exclude if the repo has a `-linguist-generated` or `-linguist-vendored` gitattribute for that directory [1]. So in your case you can add

  build/** -linguist-generated

to `.gitattributes` and once my PR lands files under `build` should be findable in file-finder.

Thanks for pointing this out! Feel free to DM me on twitter (@cbrasic) if you have more questions.

[1] Recursively matching a directory with gitattributes requires the `/**` syntax unlike .gitignore: https://git-scm.com/docs/gitattributes#:~:text=with%20a%20fe...

Yes! Use `<pattern> -linguist-generated` (the minus sets a negative override for any gitattribute).

Here's a test demonstrating that this usage works: https://github.com/github/linguist/blob/32ec19c013a7f81ffaee...

> Not applicable to GitHub etc though.

GitHub (disclosure: where I work) does respect some directives in a repo’s .gitattributes file. For example, you can use them to override language detection or mark files as generated or vendored to change diff presentation. You can also improve the diff hunk headers we generate by default by specifying e.g. `*.rb diff=ruby` (although come to think of it I don’t know why that’s necessary since we already know the filetype — I’ll look into it)

In principal there’s no reason we couldn’t extend our existing rich diff support used for diffing things like images to enhance the presentation of lockfile diffs. There’s not a huge benefit for text-based lock files but for binary ones (if such a scheme were to take off) it would be a lot more useful.

Perhaps you misinterpreted my reply. I didn’t intend to dispute parent’s claim, merely to correct a mechanical detail.

Git signatures are more or less only as secure as SHA-1, although the properties it relies on are not yet compromised and several factors mitigate the real-world risk.

A practical preimage attack on SHA-1 would seriously undermine the security of git signatures since the string being signed includes two or more SHA-1 hashes representing a content snapshot and the commit ancestry. Arbitrary preimage attacks would make it possible to modify a repo’s contents or history without invalidating oids or signatures.

In practice only collision attacks have been found, all of which have a detectable signature that git has been modified to detect.

Disclosure: I work at GitHub, but am speaking for myself.

> Instead gpg signs the SHA-1 commit digest directly

A minor correction: when signing a commit, gpg does not sign the SHA-1 digest of that commit. This is impossible since the signature becomes part of the commit header which is one of the inputs to the hash function that produces the oid.

Instead, GPG signs the serialized data (parents,headers,tree,message) which would otherwise be the input to SHA-1. Then the sig is inserted into the buffer at the end of the header and the string is digested to produce an oid.

Source: https://github.com/git/git/blob/39c15e485575089eb77c769f6da0...

This test seems to be a good example of the vulnerability: https://github.com/rubygems/rubygems.org/commit/58c755a7a62a...

That's completely fair. I think the analogy to SQL as an API is very apt. No one would argue that full SQL access isn't a powerful API but it takes some legwork to understand the schema and write queries to get the data you need.

There's a divide between at least two types of persona here. On one side is integrators building products and features on top of the GitHub API. For these people GraphQL is arguably superior since the learning curve is manageable and in exchange for scaling it you can make an extremely specific query that returns your product's exact data requirements. The cost of writing this query is amortized over the lifetime of your integration.

On the other side are e.g. users automating some part of their GitHub workflow to save themselves time. I can see how the REST API feels like a better choice here, it's certainly simpler to get started with.

For what it's worth, here[0] is an example of using the `gh` CLI's graphql feature to print a list of all repository URLs for a given organization by login, sorted in a relatively complicated way. It's more verbose than doing this with the REST API but significantly more flexible. This could just as easily be done with curl but as others have pointed out, pagination requires a minimal level of logic to implement, so it's more convenient to use an existing helper. This output gets flushed 10 lines at a time as pages come in, making it suitable to compose with other commands using pipes.

  $ gh api graphql --paginate -f query='
    query($endCursor: String) {
      organization(login: "rails") {
        repositories(first: 10, after: $endCursor,
                     orderBy: { field: STARGAZERS, direction: DESC }
        ) {
          nodes {
            url
            stargazers { 
              totalCount
            }
          }
          pageInfo { endCursor hasNextPage } # needed for auto-pagination
        }
      }
    }' -q '.data.organization.repositories.nodes.[]'
  # output follows
  {"stargazers":{"totalCount":50643},"url":"https://github.com/rails/rails"}
  {"stargazers":{"totalCount":5298},"url":"https://github.com/rails/webpacker"}
  {"stargazers":{"totalCount":4849},"url":"https://github.com/rails/thor"}
  {"stargazers":{"totalCount":4075},"url":"https://github.com/rails/jbuilder"}
  # snip
  {"stargazers":{"totalCount":3},"url":"https://github.com/rails/hide_action"}
  {"stargazers":{"totalCount":2},"url":"https://github.com/rails/gem-buildkite-config"}
  {"stargazers":{"totalCount":2},"url":"https://github.com/rails/sqlite2_adapter"}
  {"stargazers":{"totalCount":1},"url":"https://github.com/rails/fcgi_handler"}

[0]: https://gist.github.com/brasic/14222db7b3f5873b84820477cca27...

Thank you! I agree that there is more we could do to reach parity here.

Is paginating across multiple dimensions possible via the REST API?

GraphQL uses HTTP like the REST API and speaks JSON. There's no need for a library if you're comfortable sending a POST request.

It seems to me like the main friction that you and others are getting at is that GraphQL is more work to use than REST because you have to write a query. That's a fair point! Perhaps we could publish "canned" queries that are the equivalent of the most commonly used REST endpoints, or make them available for use in the API with a special param.

The GraphQL API works just as well with curl. There's no getting around the fact that you need to pass a query text but assuming you put the query in a file the curl syntax is identical to the REST API:

   curl https://api.github.com/graphql -H "Authorization: bearer $TOKEN" --data @query.graphql