acrispino's comments

On: Redis re-implemented with SQLite

[acrispino]

for what it's worth, the two pool approach is suggested here by a collaborator to github.com/mattn/go-sqlite3: https://github.com/mattn/go-sqlite3/issues/1179#issuecomment...

On: Htmx vs. React: A Complete Comparison – Semaphore

[acrispino]

Where is this promise on the htmx website?

On: J vs. K by Example (2005)

[acrispino]

Look at one of the captures around the end of 2021.

On: Express.js repo swamped with spam PRs thanks to Yo...

[acrispino]

You might be thinking of digital ocean's hacktoberfest

On: The Design of SQLite4 (2014)

[acrispino]

Strict tables were added with 3.37.0, does that help? https://www.sqlite.org/stricttables.html

One issue I've run into while using strict tables is that since sqlite does not (yet?) have a dedicated type for timestamps, a driver like github.com/mattn/go-sqlite3 use the typename in the schema to determine when a column can be converted to a native time datatype. But STRICT tables only allow 6 specific typenames: INT, INTEGER, REAL, TEXT, BLOB, ANY

[skissane → acrispino]

> One issue I've run into while using strict tables is that since sqlite does not (yet?) have a dedicated type for timestamps, a driver like github.com/mattn/go-sqlite3 use the typename in the schema to determine when a column can be converted to a native time datatype. But STRICT tables only allow 6 specific typenames: INT, INTEGER, REAL, TEXT, BLOB, ANY

I wish they’d implement CREATE DOMAIN, like Postgres has. Using it you can define a named custom type from a base type, optionally with associated CHECK constraints. A minimal implementation would skip the constraints (and DEFAULT and collation) and just let you do CREATE DOMAIN timestamp AS INT (or TEXT if you’d rather do it that way), and thereafter STRICT tables could have timestamp as column type

Previous comment of mine which explains this in more detail: https://news.ycombinator.com/item?id=29367517

On: AMD Open-Source GPU Kernel Driver Above 5M Lines, ...

[acrispino]

It's not open source unless you can have it your way? That's too picky, for me

On: Google is already pushing WEI into Chromium

[acrispino]

From the explainer:

> However, a holdback also has significant drawbacks. In our use cases and capabilities survey, we have identified a number of critical use cases for deterministic platform integrity attestation. These use cases currently rely on client fingerprinting. A deterministic but limited-entropy attestation would obviate the need for invasive fingerprinting here, and has the potential to usher in more privacy-positive practices in the long-term.

I think any holdback will eventually go away because of the "critical use cases for deterministic platform integrity attestation"

On: Comic Code: Monospaced interpretation of the most ...

[acrispino]

They are close but when I look at them side by side I give the edge to Comic Code. With Comic Mono I think the lines are a little too thick. Other things I notice, : is too small and <> are too big. YMMV of course

Also, while the complete set of Comic Code is $100, there's a "coding essentials" pack for $30

On: The future of AlmaLinux

[acrispino]

CentOS Stream doesn't do minor releases and I assume AlmaLinux will continue making minor releases as they already do. Not everyone cares about that but some will.

[jonathanspw → acrispino]

Correct we will continue with minor releases every ~6 months.

On: Impact of RHEL Changes to AlmaLinux

[acrispino]

Isn't Rocky in the same boat? It doesn't seem they have any more access to RHEL sources than Alma does.