flakes

A selfie at that resolution would be some sort of super-resolution microscopy.

You can, and that is mentioned in RFC 9110... along with the cons for doing so.

> Although request message framing is independent of the method used, content received in a GET request has no generally defined semantics, cannot alter the meaning or target of the request, and might lead some implementations to reject the request and close the connection because of its potential as a request smuggling attack (Section 11.2 of [HTTP/1.1]). A client SHOULD NOT generate content in a GET request unless it is made directly to an origin server that has previously indicated, in or out of band, that such a request has a purpose and will be adequately supported. An origin server SHOULD NOT rely on private agreements to receive content, since participants in HTTP communication are often unaware of intermediaries along the request chain.

QUERY is a new option to help avoid some of those downsides.

https://www.rfc-editor.org/rfc/rfc9110.html#section-9.3.1

Yeah, I just always used the context windows to set permalink. Saves me a step now!

> unless I'm missing something I don't think a QUERY verb will change all that much here?

The semantics are important. GET APIs are expected to be safe, idempotent, and cache-friendly. When you are unable to use GET for technical reasons and move to POST, suddenly none of the infrastructure (like routers, gateways, or generic http libs) can make these assumptions about your API. For example, many tools will not attempt to put retry logic around POST calls, because they cannot be sure that retrying is safe.

Having the QUERY verb allows us to overcome the technical limitations of GET without having to drop the safety expectations.

I had no idea there was a hotkey for that. Thank you!

Another great post from Arse Technica

What does “4x the peak GPU compute performance” mean here? No latency difference, but higher throughput? The footnote was not at all helpful

> Performance tests are conducted using specific computer systems and reflect the approximate performance of MacBook Pro.

> I absolutely loathe the amount of brute-force memorization that is required to operate a command-line efficiently. It took YEARS to memorize simple linux shit

Not to invalidate your experience, but you shouldn’t need to memorize too much to use the common command line tools (although it does always help to have more experience using them).

I recommend always keeping a second terminal session open, purely for referencing man pages. You should be able to see most options easily, or be able to grep for the instructions you need.

The tight integration between documentation within the CLI, coupled to the exact software version you have installed, helps immensely when invoking CLI tools.

For the common linux tooling, found in most distros (e.g. coreutils or common busybox ops) the documentation in man pages is quite excellent.

> In theory, a PC builder could try exchanging heat to a toilet tank, allowing for highly efficient cooling with each flush.

The future is here.

Curious, what were you using for doing syscall logging? LD_PRELOAD tricks, or ebpf filtering?

Perhaps it makes more sense to say that exported function interfaces be explicit. That forces you to document the api and more carefully consider changes.

Im a firm believer that there will never be a perfect general purpose job scheduler. The priority for how jobs are scheduled is always deeply coupled to your business needs. General purpose schedulers always end up as a jack of all trades but master of none. With a custom built scheduler you get that control, but do have to re-invent the wheel for a lot of features. Jenkins, Argo, Airflow, Cron, etc, all have their own pros and cons.

It’s a tradeoff. Ease of modeling the pipelines vs ease of managing the infrastructure. Im not really a fan of either syntax for defining DAGs, but they're the best options out there imo.

After using Argo Workflows, I don't think I will ever return to Airflow. Kubernetes is not an easy system to manage, but managing an Airflow setup is somehow worse. The story around disaster recovery and scheduler redundancy was an absolute nightmare for me.

Jenkins is a place where you can be safe for a long time, however, it starts to break down at scale. I see it time after time for these batch workflow jobs. At the start, jobs run in seconds and everyone is happy.

Over time, jobs start taking long enough to the point where you need to split them. Separate jobs are assigned slices of the original batch. Eventually, there are so many slices that you make a Jenkins job where the sole responsibility is firing off these individual jobs.

Then you start hitting the real painpoints in Jenkins. Poor allocation of jobs across your nodes/agents, often overloading CPU/Mem on machines, and you struggle to manage the ungodly interface that is the Jenkins REST endpoint. You install many Jenkins addons to try and address the scheduling problems, and end up with a team dedicated to managing this Jenkins infrastructure.

The scaling struggles continue to amass and you end up needing separate Jenkins instances to battle the load. Any attempt at replacing the Jenkins infrastructure goes on standstill, as the amount of random scripts found in Jenkinsfiles has created an insurmountable vendor lock-in.

You read a post about a select-for-update job scheduler and reflect on simpler times. You cry as you refactor your Jenkins Groovy DSL.

Seems prone to deadlocking- I would avoid making the thread-pool globally scoped, and instead provide it as arguments to the helper methods.

You could argue the same thing (forcing kwargs) for all Python functions/methods, although, that would make using your APIs very annoying. The `__init__` method for dataclasses are just another method like any other.

As a general rule of thumb, I only start forcing kwargs once I'm looking at above 4-5 arguments, or if the arguments are similar enough that forcing kwargs makes the calling code more readable. For a small number of distinct arguments, forcing kwargs as a blanket rule makes the code verbose for little gain IMO.

Ah very nice! Did not realize this was a part of the standard library!

Probably because a large amount of AIs are churning out Python code, and they need type-checkers to sanitize/validate that output quickly. Dynamic languages are hard enough for people to make sense of half the time, and I bet AI agents are struggling even more.

Really loving those markdown style tests. I think it's a really fantastic idea that allows the tests to easily act as documentation too.

Can you explain how you came up with this solution? Rust docs code-examples inspired?

It has it's niche uses, such as compiling Go for lesser used architectures. It's a bit awkward to not have full language capabilities, but it still feels nicer than writing C/C++.

On one of my internships there was a small handheld radio floating around the office. I changed it to some local AM jazz station, set it to the lowest possible volume (such that it was barely audible), and hid the radio inside another interns desktop. I told the other interns about it, and we agreed that whenever he asked anyone if they could hear music, that we would tell him we couldn't hear anything.

At first he seemed mildly annoyed but mostly ignored it. You couldn't always hear it depending on what song was playing, so that helped keep it hidden for a while. Fast forward one week, we came back from lunch to find that the guy had disassembled almost everything in his cubicle before finding it. He angrily held up the radio and called us all jackasses. I have a little chuckle every time I remember this!

That still has the same issues depending on the usage. The default construct here is `NotificationWrapper{nil}`. If you want to actually guard it, you also need to make the Value field private as that nil becomes part of your public api otherwise.

    type NotificationWrapper struct {
        // This field holds the actual notification data
        value interface{}
    }

Within `ProcessNotification` you'd also want to always assert the struct is initialized. You have to handle that error case via `err` or `panic`.

With a true sum type, you could be assured that the value is always concrete, removing the need for error handling, which otherwise complicates the business logic of your application. Errors that should be safeguarded against by the compiler become run time checks, eating up cycles on the CPU, or paniced upon, potentially leading to segfaults which can only be caught by tests (not asserted valid via the act of compiling).

The problem I have here, is that by being an interface you’ve suddenly made the type nilable. This leads to nasty bugs and segfaults, especially where nil is the default construct for all interfaces.

Ideally sum types would be concrete/non-nilable somehow.

That link I sent is an example of standard notation I used when playing set. For accents, something like bigger or smaller circles could work fine.

Purdie shuffle would look like:

       1  2  3  4 
   hh |x-xx-xx-xx-x|
   S  |-o--o-Oo--o-|
   B  |o----o-----o|

Or something like a basic jazz shuffle:

       1  2  3  4 
   hh |x--x-xx--x-x|
   S  |---o-----o--|
   B  |o--o--o--o--|

Some other ideas:

- 2 bar patterns would also be great. Many patterns repeat over 8 quarters.

- Allowing accents (dynamics). A lot of drum patterns involve just a few drums, where accents are what bring the pattern to life.

With accents and triplets, you can have the Purdie shuffle [1], which is one of my favorite patterns ever :)

:[1] https://tomtommag.com/wp-content/uploads/2011/10/Purdie-Shuf...

Please allow triplets! You're missing out big without a basic shuffle! I also second the other comments about ordering. Cymbals on top, snare and toms in middle, bass and other pedals on the bottom. e.g.

   hh |x-x-x-x-x-x-x-x-|
   S  |----o-------o---|
   B  |o-------o-o-----|

HL1 is a very different experience compared to HL2. If you haven't played through HL2 I would still give that a shot. I love both games, but the second one was a lot more polished.

> Python has been losing users to Rust. I don't entirely understand that, other than everyone saying how Rust's tooling is so much better.

Not to rust, but to Go and C++ for myself. The biggest motivating factor is deployment ease. It is so difficult to offer a nice client install process when large virtual environments are involved. Static executables solve so many painpoints for me in this arena. Rust would probably shine here as well.

If its for some internal bespoke process, I do enjoy using Python. For tooling shipped to client environments, I now tend to steer clear of it.

> converts programs that will run out of stack eventually regardless of the amount of available memory (and raise exceptions an the process, for example, which a program might rely on

https://xkcd.com/1172/