It would, but it does not have SATA. You can find much cheaper computers that do have it

For a server like this 4GB of DDR4 is enough. And that is cheap still.

That’s a good point, months would need new names. And dates should have some other format, maybe a F prefix: FYYYY-MM-DD

Ah, another oppurtunity to bring up international fixed calendar that could reuse the calendar every year!

Let’s say I manage an engineering department. How could I promote people who build simple software?

Woah, they take the blame and apologize. This is not often seen and commands respect.

This looks … great.

Ha. Lol. That’s bad

Context: this happens if you use patch(1) with patches generated by git format-patch. If you do, you should be using git am instead.

I wouldn’t call it state-of-the-art, but rather maybe most-straightforward or database-agnostic or as-simple-as-they-get

Yes. Highlighting, these selection actions and symbol detection all work with tree-sitter grammars. The whole premise of the editor is a modern-modal-editing with tree-sitter grammars.

I’m a bit surprised helix editor is not mentioned. It is based on tree-sitter grammars and allows for stuff like select-around-function or select-around-argument, to use grammar in the code navigation. Pretty wild and useful.

You are either a crazy nutjob or a genius thinker. Interesting idea

Wikipedia to the rescue:

However, some formats (ex., HDV, DVCPRO HD) use non-square pixels internally for image storage, as a way to reduce the amount of data that must be processed, thus limiting the necessary transfer rates and maintaining compatibility with existing interfaces.

Actual displays do not generally have non-square pixels, though digital sensors might;

TLDR; some formats use non-square pixels for reducing file size, some digital sensors has non-square pixels.

Does anyone know why anyone would want to encode their video using PAR != 1? Reducing the file size, by storing less pixels in one dimension, but not the other?

I do believe that it is possible to translate any SQL query to Lutra, that is Lutra can cover that last 1% of cases. There are a few caveats:

• Some cases would produce very verbose Lutra code because they have special-case syntax in SQL, which makes them terse.
• Lutra does not cover DDL (CREATE, ALTER, DROP, ADMINISTER). That’s because Lutra is conceptually a “run-time” language for dealing with data and not schema modifications. Because of this, Lutra cannot be used for migrations.
• Lutra is still in development, so you are likely to find cases that are not yet expressible. If you do, please report them, so they can be implemented. But I don’t believe that there are cases that would conceptually clash with Lutra language design, like there are with most ORMs.

Two great questions!

First one comes down to how database query optimization and predicate pushdown in particular. In this case, albums would probably have an index on albums.id column, which would optimize get_album_by_id into a single index lookup. Ideally, I would want to have an explicit function for this, something like sql::from_index("albums", "id", 3), but there is no such thing as explicit index lookup in PostgreSQL right now.

Regarding different function syntaxes:

• curly braces { ... } construct a new tuple (think object, struct, record),
• parenthesis are used for precedence. They are not strictly needed for function bodies, but they do give a better visual guide to multi-line definitions, especially when using pipe operator.

So:

func something() -> { ... }  # constructs a new tuple
func something() -> ( ... )  # returns a value
func something() -> ...      # equivalent to ( ... )

I think that ORMs work great for 90% of cases, and abismally for the rest. They are also limited by the syntax and semantics of the language they are embedded in. For example, if you refer to a non-existing column, it would take a call to database to figure that out, and a cryptic error message with non-helpful code span.

Haven’t thought about but yes - it solves a few of the same problems as ORMs. Maybe the front page does not mention it, but with Lutra, you don’t get result.getInt(). You get generated Python classes / Rust structs that reflect the Lutra types.

I’m currently looking into Concourse.

It does have steeper-than-average learning curve, but I really like that it has well-defined fundamentals (resources, jobs, tasks) and isolation with OCI containers. Before I adopt it fully, I want it to run my nix flake dev shell.