fipar

When I read that I assumed "you" meant the people building and training AI, not the whole of humanity. Doesn't mean I'm right, of course, but I wanted to offer that perspective.

Since I first read it in Spanish, I went back to read it in English and I still get my first interpretation.

In particular, "We have come to speak to you about the intelligence you are building." set the association in my head of "you == those building the AI"

I really like those videos too, but a very big difference is, in manufacturing QA, the system outputs a very high number of copies of a very small number of possible types, so spot checks work fine from an operations research point of view, as the variance in output has a known upper bound.

For code, I think things go in the opposite direction: the system outputs artifacts that are all different among themselves (even more so now that we no longer distribute software via physical copies. Well, bits are always physical, but I mean we no longer ship floppies/CDs/DVDs).

That said, at least in my experience, code review has never been a direct part of factory-line-type QA. That QA is typically done by treating software as a black box and just verifying that it complies with a spec (often times based on a very loose definition of "spec" ...), and this is something that works equally well regardless of whether a human or a machine wrote the software. The type of QA that is done (among other things) by code reviews is checking whether the software's design is such that it will be economically feasible to maintain and extend it, for example.

The one part the code reviews takes a part of (but is in no way error-free) and that you just can't do with black-box testing (or it is much harder to do) is to look for things like backdoors. As our industry moves more towards "agents write software and tests validate that it works," I think a lot about "Reflections on Trusting Trust" and the new and wide attack surface added by people no longer reading the code shipped on their behalf.

Bass players too!

At least that's the story I've read online a few times about the bass sound on Sir Psycho Sexy having to do with the dying battery on the pedal.

And, of course, just a little bit before DSP and simulators become available (or feasible for mainstream availability), those of us who were playing as teenagers in the 90s often got weird sounds on account of trying to juice the last bit of the batteries in our pedals. I love it that some among the current generation of kids like to simulate tape hiss, dying batteries, and other things we'd suffer then :)

I don't remember the specifics but I can confirm he was brave :)

I know a local company at some point had a disk-drive-like interface to better use tapes (HiLow Datadrive) so maybe he had that, because saving work to cassette the way I saved things to cassette in the 80s would have been painful (not that it wasn't painful in the 80s of course!)

My recollection is it was basically the same computer he had since the 80s. I always have trouble identifying a specific sinclair version because I had clones (tk-90x, then tk-95).

Just as some perspective: in Uruguay in ‘93 things were still all over the place. I was still running an XT until about the end of the year, where we jumped straight to a 486 (alas… SX). And as late as ‘95 I had a classmate (who went on to graduate as both electrical and computer engineer) who was doing high school papers on a Spectrum.

Thanks for the book recommendation.

I agree that a computer is not a biological being. I think current LLM-based AIs are not conscious but, as to “everything else we normally associate with consciousness is biological and living,” while I agree that’s currently the case, if I look at AI (in general; not just at what’s popular now) through the lens of Pirsig’s Metaphysics of Quality, consciousness is on the Intellectual level (IIRC he classified what he referred to as Quality into Static/Dynamic and inorganic, organic, social, and intellectual).

A priori, there’s no reason why a level couldn’t be skipped and have intelectual patterns be supported directly in inorganic ones, skipping the biological (I think also the cultural, because if an AI ever is conscious we might as well call it alien and not just artificial: it would be so different from anything we know that it may just come from another galaxy, and it may not need a cultural substrate either).

Same for me but on the Spectrum's illegitimate South American cousin, the TK-90X :)

The language is still alive but I think Scratch has mostly taken its place.

I’ve only seen videos of this keyboard but never played one. With that disclaimer out of the way, the price is comparable to mid-range clavinova models.

The clavinova does have a piano-like body, very very good built in sounds (including binaural for 2 types of piano in mine), and built in speakers, so there’s that.

On the other hand, this one says “built to order” while clavinovas are not.

All this to say that, while expensive, it does not seem outrageous if the keyboard plays good. This one has after touch too, which makes it more comparable with a synth than a digital piano (though I understand this one is just a controller).

“For example, if a philosophical zombie were poked with a sharp object, it would not feel any pain, but it would react exactly the way any conscious human would”

Doing non-verbal thinking has nothing to do with not feeling pain, I don’t think it sounds like philosophical zombies at all.

Yeah, looking back at my first reply I did get the order wrong: first the alter, then the empty noop. But once you run the alter and have a primary key (though the author clarified the table did have a PK already), I’d just use pt-osc to run the empty noop as that would basically do what the manual says.

Nice seeing you Evan! :)

That makes sense then.

If the table had a primary key, in case you ever face such a setup again (hopefully not!) then I think pt-online-schema-change to add the auto increment primary key while using ROW would probably be a better choice than the steps I mentioned in my first reply. It will rebuild the table anyway but at least it won’t block it while that happens.

The "relational" in relational databases is not about department number in employees referencing departments.

What the model calls relations are sets of n-tuples where each attribute value has a domain.

SQL databases call their version of relations tables, and, in that view, a database with a single table is still relational.

Now I don't think SQL databases are relational but the analogy still holds (I'd just say that a relational database can have just a single relation)

If you meant it this way and I misunderstood you, apologies, though I'm not sure I'd say most data is actually inherently relational (even though I do think the relational model is the best one we have so far for databases).

However, if you meant that most data has relationships (as the ones we enforce with foreign keys in sql databases) then I agree with you, and I think using database management systems that don't have good support for representing this type of relationships between data entities will only work in niche cases and will eventually cause more trouble than benefits in general-purpose use cases.

I think it happened right after the alter table, but it was discovered after the upgrade. It's normal to have more eyes on the system after a DB upgrade, and also common to blame the DB for post-upgrade problems.

Turns out this time the DB was to blame, but not because of the upgrade.

If the alter table in the blog post is not a simplified version of what was executed (barring changing column names, of course), that means the table had no primary key before the migration, which is a problem on its own.

To be honest, I don't even know if there's a safe way out of that situation in a replication setup, but one plan I would have tried to test in that situation is: - switch binlog_format to ROW (and never look back ...) - run a noop alter table to rebuild the table and hope that with ROW format, the rows get inserted in the same order (hope really hard please, with feeling) - run the alter table

Fortunately, recent versions of MySQL have ROW as the default binlog_format.

I think that's a good approach, whether it works on not probably depends on the nature of the work you want it to do.

In my case, given I work with databases, there's little that agents can do on their own except in the exploratory phase. I have run exploratory phases in self-contained VMs, including containerized DBs within the VM, but when it comes to go to prod, my endpoint could be used to launch a career ending event so I prefer to stay with the current approach. I'm still moving way faster than just 1 year ago, but in a safe way.

But I can totally see your approach working in other scenarios.

When I'm not too pessimistic, I agree with you on the result being a systemic hardening. I just hope the incidents that happen on the way to that hardening aren't too bad.