metrognome

To play devil's advocate here, imagine a world where the exact opposite has occurred: physical media (CDs specifically) is the norm, and there's no DRM, so the raw data can be copied right off of it. In this world, scalpers scoop up all available inventory of physical media from local retailers, consumers pay a premium to them for the original product, the scalpers sell cheaper copies where the game binary has been modified to insert advertisements or mine cryptocurrency, out of the woodwork appears a cottage industry of companies offering services to modify game binaries and connect them to the ad networks and crypto exchanges. The scalper gets a cut, the gamer gets a cheaper game, everyone is happy.

I'm with you but I see a bigger problem. I'm not sure if you noticed but there are threads of low desire within our society. Young people, in particular young men, increasingly seem to be checking out of dating and higher education, both examples being paths towards enriching oneself. As these people age, lose mental plasticity, and become entrenched in their ways, how likely are we to be able to convince them to begin valuing those things again?

I'm less concerned about the impact of AI specifically and more about concerned about people simply losing the will for one another or anything at all. None of this stuff in the real world will matter too much if people are getting their basic needs and desires met in a virtual one.

The rhetoric of this comment seems to imply that this is a bad thing, but is it really? If it becomes more difficult to make money through creative endeavors, then that leaves us with fewer reasons to be creative other than for the sake of self-expression... which is what we want, right?

Zen of Python in 2025:

  There should be one-- and preferably only one --obvious way to do it.

Python String Formatting in 2025:

- t-strings

- f-strings

- %-operator

- +-operator

- str.format()

I'm surprised that there's been no mention of Operation Paperclip, neither in the article nor in the comments here. Seems like a huge part of the story to leave out.

https://en.m.wikipedia.org/wiki/Operation_Paperclip

I'm going to leave this here for anyone who wants some good focus-time music: https://youtu.be/Do5_wU9X1pc

It's about writing code that your peers can read. "DO NOT SUBMIT" is clear as day. "ASDFASD" probably does not mean "this is a debugging string" to most people.

I live in California.

I live in an apartment complex that uses RealPage. My roommates and I re-signed the lease earlier this year, with a projected 15% rent price increase. We then walked to our leasing office to ask about it, they simply cancelled the increase. We're now paying the same rate we were last year.

I am fairly certain that 15% increase was the automatic recommendation by RealPage.

According to the article, he disappeared in 1976 (48 years ago). Apologies for the pedantry.

There are plenty of projects smaller than the Linux kernel that have developed and employed DSLs (to varying degrees of success, I'll grant). I wonder, are there any languages out there designed specifically for kernel programming?

Given the number of preprocessor hacks used in the kernel, and the amount of GCC-specific behavior that the codebase depends on, it seems like they are already halfway there.

I gained a a few years of experience in SQL-based OLAP systems at my current job. In this time I developed a strong appreciation for SQL, especially for its composability. Recently, I started a project in Google Colab, gluing together queries from several systems with Pandas DataFrames. I can honestly say that I've never been more frustrated learning an API than I have with Pandas.

Need some window function like LAG() or LEAD()? Too bad, I hope you like writing Python "for i in range(...):" loops. My notebook is littered with ".reset_index()" calls, ".replace(np.nan, None)", "axis='columns'", "foo.assign(bar=lambda df: df.apply(lambda row: ...))". groupby is especially confusing to me, as a Pandas GroupBy is difficult to compose with a normal DataFrame until you call .reset_index(). Compare this to SQL, where a subquery is a subquery, whether or not it has a GROUP BY clause.

The Pandas documentation also leaves a lot to be desired. Take the documentation of pandas.NaT[1] for example. "pandas.NaT: alias of NaT". Ok? That still doesn't tell me what NaT is, nor does it link to the thing that it aliases. The groupby documentation[2] also caused me some headaches, as it covers only the simplest aggregation use-cases.

Pandas is clearly better for some use-cases, but mostly for simple operations that are well-supported by the API (perhaps numeric operations that are implemented with native numpy routines). But if I'm doing some interactive OLAP stuff, I'll reach for SQL. Perhaps the problem is I'm trying to use Pandas like it's SQL, when it's not. But for manipulating data, I'd rather use a language than a library.

[1] https://pandas.pydata.org/docs/reference/api/pandas.NaT.html [2] https://pandas.pydata.org/docs/user_guide/groupby.html

edit: half a sentence

Remember everyone, your bubbles are green because you have an iPhone, not because the person you are texting has an Android.

For the mixing and mastering aspect of music production, look no further than Dan Worrall:

https://www.youtube.com/playlist?list=PL6e8wfdmIuLEDpO3rd5jO...

https://www.youtube.com/playlist?list=PLNNHQbT3rbzXwLY0E_-o9...

Oh, I'm not arguing that using checksums, SHA for example, for integrity verification is a bad idea. That's what they're designed for, after all.

However, I do think it's a bad idea to enforce the content of compressed archives to be deterministic. tar has never specified an ordering of its contents. Compression algorithms are parameterized for time and space, so their output should not be deterministic either. Both of these principles apply to zip as well. But we now have a situation where we are depending on both the archive format and the compression algorithm to produce a deterministic output. If we expect archives to behave this way in general, we set a bad precedent for all sorts of systems, not just git and GitHub.

I wonder if this incident will encourage our industry to build more robust forms of artifact integrity verification, or if we will instead codify the status quo of "we guarantee repos to be archived deterministically." To me, the latter seems like a more troubling precedent.

Per the post, this was a change to git itself: https://github.com/git/git/commit/4f4be00d302bc52d0d9d5a3d47...

There's more nuance to it than that, so let me try to clarify again. Like you said, the accelerometer shows the difference between the casing's reference frame and the internal's reference frame. The internals ideally maintain an inertial reference frame. It's only "designed" to show 0g in free-fall because the difference between the reference frames of the casing and internals _is_ 0 when you are falling. Because, again, when you are falling, you are in an inertial reference frame - you are not accelerating against the flow of spacetime.

The only time the accelerometer reads something other than 0 is when something pushes it away from an inertial reference frame. This is true when you're on the ground: spacetime is curved, and "flows" towards the center of the Earth. The ground pushes you against the flow of spacetime, and the difference between these two frames of reference is 1g. Note that this 1g is not "caused" by gravity, it's caused by the electromagnetic force. Forces push matter away from an inertial reference frame. Gravity is different. It decides where an inertial reference frame goes by curving spacetime - it is not a force.

Hypothetically, if you were are the center of the Earth, the accelerometer would read 0g. There would be nothing pushing you in any particular direction - you would be in an inertial reference frame (ignoring the minor detail of being crushed by all of the Earth's mass).

Again, I'm trying to show the subtle difference between accelerating compared to a fixed coordinate system, and accelerating compared to an inertial reference frame. The fixed coordinate system does not take into account the curvature of spacetime. If it did, the coordinates would be "accelerating" towards the center of the Earth at 1g - congratulations, you've defined an inertial reference frame.

I hope that makes sense. It blew my mind when this idea clicked: that space and time are not two distinct things, they are two parts of the same thing.

There's a difference between accelerating compared to a coordinate system, and accelerating compared to an inertial rest frame. If you set a fixed coordinate system relative to the ground, then yes, the cat is accelerating towards the ground.

Consider this: if you hold an accelerometer while stationary on the ground, it will read 1g (accelerating). If you read an accelerometer while in free-fall, it will read 0g (ignoring wind resistance). In the first scenario, you are accelerating compared to your rest frame, even if you are standing still.

This is not an arbitrary distinction either. The 1g of acceleration while stationary on the ground produces measurable relativistic effects.

While falling, the cat is in an inertial reference frame, so it is not accelerating. The ground is actually accelerating upward at 9.8 m/s2, counteracting the flow of spacetime.

This Veritasium video gives an intuitive explanation: https://youtu.be/XRr1kaXKBsU

The pattern of holes technique in that link (MURA) is also used in UV lithography for IC fabrication (example: https://youtu.be/8eT1jaHmlx8?t=1543).

Just to note, for this specific example, Go supports this with type definitions:

  // UserID and PostID are distinct types
  type UserID int
  
  type PostID int

It's not too surprising that there are fewer unique products for a geometric progression, because subsequent terms in a geometric progression are found by multiplying by the common ratio. There will be fewer unique products when all of the numbers share that common ratio.

Quite often, I accidentally press the space bar eagerly when typing git commands:

    $ gi tstatus

To fix this, I've added the following to my .bashrc:

    gi() {
        args=("$@")
        args[0]=${args[0]/t/}
        git "${args[@]}"
    }

It also works if you drop the "t" altogether.

Vyacheslav Egorov wrote an article[0] on monomorphic function calls and how they impact JavaScript performance. While it's very in-depth, it is over 2 years old at this point, so I'm not sure how well it applies to the current version of V8.

[0] http://mrale.ph/blog/2015/01/11/whats-up-with-monomorphism.h...

The Magic Keyboard does have the new switches, or at least the first generation butterfly switches that the first generation MacBook had. Also, there is more key travel on the Magic Keyboard than on the MacBook or the MacBook Pro.

Orange Marmalade.

I think Gary's commit counts are off:

  $ git log | wc -l

This should count the number of lines in the entire git log, including metadata (not just commits). I think he means this:

  $ git log --oneline | wc -l

The number of commits for Rails should be closer to 61,000.