Using Python and SGQLC with Shopify’s latest API (2025-01):
$ python3 -m sgqlc.introspection https://<subdomain>.myshopify.com/admin/api/2025-01/graphql.json -H "X-Shopify-Access-Token: <secret>"
{
"data": {
"__schema": {
"directives": [
{
"args": [
{
"defaultValue": "null",
...Incidentally, Shopify’s Python client establishes the schema’s URL here:
If the kernel identifies that a file you’re trying to execute has a known sequence of magic bytes, it will happily execute it. However, you might want to run certain formats without needing to pass them to another tool. In as much as these are usually binary tools, you can prepend a magic-bytes preamble (or use an existing sequence, if your binary format already declares one) and then associate that with a certain loader in the running kernel using binfmt_misc. Access is usually via procfs (currently /proc/sys/fs/binfmt_misc/register). Cross-execution with a virtualized process is a common use-case for this.
Note that this doesn’t really apply to text files (it’s all data) because you’d need to inject gibberish at the top of your file to use this functionality when using a shebang (which is meant for this case) should work just fine.
This is a walkthrough of how to do this for compiled Python or LUA source-code: https://twdev.blog/2024/01/docker_multi_platform
Since both of the example compilation formats include magic bytes, you can just write a tool to acquire those from libraries (at least with Python) and call binfmt_misc in one step.
You can also write configs to be automatically loaded at boot. There appears to be no way to list registered formats, with the only recourse being to sift the config paths (probably empty by default) or to check your kernel config to see which supported formats were included in that build.
From the overview:
Computers once had operator panels that provided an intimate overview of the machine’s internal state at any given moment. The blinking lights would communicate the personality of each piece of software. Since our minds are great at spotting patterns, developers would intuitively understand based on which way the LEDs were flashing, if a program was sorting data, collating, caught in an infinite loop, etc. This is an aspect of the computing experience that modern machines haven’t done a good job at recreating, until now.
https://github.com/github/git-sizer
Notice that it cites the revisions at the bottom:
$ git-sizer -v
Processing blobs: 2049
Processing trees: 1056
Processing commits: 432
Matching commits to trees: 432
Processing annotated tags: 0
Processing references: 12
| Name | Value | Level of concern |
| ---------------------------- | --------- | ------------------------------ |
| Overall repository size | | |
| * Commits | | |
| * Count | 432 | |
| * Total size | 143 KiB | |
| * Trees | | |
| * Count | 1.06 k | |
| * Total size | 885 KiB | |
| * Total tree entries | 21.0 k | |
| * Blobs | | |
| * Count | 2.05 k | |
| * Total size | 33.8 MiB | |
| * Annotated tags | | |
| * Count | 0 | |
| * References | | |
| * Count | 12 | |
| | | |
| Biggest objects | | |
| * Commits | | |
| * Maximum size [1] | 1.32 KiB | |
| * Maximum parents [2] | 2 | |
| * Trees | | |
| * Maximum entries [3] | 66 | |
| * Blobs | | |
| * Maximum size [4] | 4.05 MiB | |
| | | |
| History structure | | |
| * Maximum history depth | 413 | |
| * Maximum tag depth | 0 | |
| | | |
| Biggest checkouts | | |
| * Number of directories [5] | 27 | |
| * Maximum path depth [6] | 4 | |
| * Maximum path length [7] | 105 B | * |
| * Number of files [6] | 137 | |
| * Total size of files [8] | 4.64 MiB | |
| * Number of symlinks | 0 | |
| * Number of submodules | 0 | |
[1] a52f2b2c86baa9617ed66bc0b3301d57bf763ed3
[2] fa562d025143096dc8ae0c2294114cd0b4443945 (refs/stash)
[3] 4ca9fdb84fec68c38d6061441996fd15b9494e9d (d2a75bc4b9743a3decf9e6cd5cb4a8670d57f30d^{tree})
[4] 62918aac7359d32b4b342db8d65a5a2a5172215d (86c3344be1fc590ee3ebe9eb7117e91c4ad21450:command/gozipinfo/gozipinfo)
[5] 2b5b648f5e6488420c22ba9c318fc6bfc4ce2a47 (461bbd7555360a202d1ab16f02c992581791a7d2^{tree})
[6] 853678df5f5fe5ec58b169d0fe3878e376c53e3e (refs/heads/dustin/profiling/temp_path^{tree})
[7] 8b03f6bab9d3369fec1fe322f5d3f159a220d95a (1b385e1714b7904fca85943d0f27c7f772af6d0f^{tree})
[8] a557ab9aff02167856530cf536163d349e44fdfe (86c3344be1fc590ee3ebe9eb7117e91c4ad21450^{tree})
Plugins are Go’s system for developing shared-libraries. However, this is backed by a general system that can also have alternative implementations. In this case, you can write a plugin in Go that runs from one system and load that plugin in Go, on the fly, from a million other systems. Courtesy of Hashicorp.
https://github.com/hashicorp/go-plugin
Installing the knockd daemon, and configuring the sequence and packet types to be used to open and close ports, and using the knock client to actually do it from the other side:
https://www.howtogeek.com/442733/how-to-use-port-knocking-on-linux-and-why-you-shouldnt/
@plzasm
A new project to recursively scan through a tree of images and determine which were captured as part of an auto-bracketing image capture operation.
Example:
$ bif_find tests/assets/images --json
[
{
"entries": [
{
"exposure_value": 0.0,
"rel_filepath": "DSC08196.JPG",
"timestamp": "2019-02-13T00:31:50"
},
{
"exposure_value": -0.7,
"rel_filepath": "DSC08197.JPG",
"timestamp": "2019-02-13T00:31:50"
},
{
"exposure_value": 0.7,
"rel_filepath": "DSC08198.JPG",
"timestamp": "2019-02-13T00:31:50"
},
{
"exposure_value": -1.3,
"rel_filepath": "DSC08199.JPG",
"timestamp": "2019-02-13T00:31:50"
},
{
"exposure_value": 1.3,
"rel_filepath": "DSC08200.JPG",
"timestamp": "2019-02-13T00:31:51"
}
],
"type": "periodic"
},
{
"entries": [
{
"exposure_value": 0.0,
"rel_filepath": "DSC08201.JPG",
"timestamp": "2019-02-13T00:32:09"
},
{
"exposure_value": -0.7,
"rel_filepath": "DSC08202.JPG",
"timestamp": "2019-02-13T00:32:09"
},
{
"exposure_value": 0.7,
"rel_filepath": "DSC08203.JPG",
"timestamp": "2019-02-13T00:32:10"
},
{
"exposure_value": -1.3,
"rel_filepath": "DSC08204.JPG",
"timestamp": "2019-02-13T00:32:10"
},
{
"exposure_value": 1.3,
"rel_filepath": "DSC08205.JPG",
"timestamp": "2019-02-13T00:32:10"
}
],
"type": "periodic"
}
]
go-github-reminders is a project that you can schedule in order to receive periodic emails of recently updated Github issues that you are involved in (technically, subscribed to) that you have not recently responded to.
For those of us with a lot to do, this keeps us on top of things.
Random Engineering 
You must be logged in to post a comment.