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.
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.
Author here. The table did actually have a primary key, during the migration it was changed to unique, and then the new auto-incremental primary key was added.
I've updated the article to make that part clear.
I agree that having the binlog_format to ROW is the only option that make sense, which thankfully seems to be the default now.
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.
I agree the root cause here is the lack of a primary key to begin with. But as far as I know, DDL is always replicated as just a statement, regardless of session binlog_format. So I believe the only real fix here is the general approach suggested in the manual [1], i.e. create a new empty table that has the auto_increment PK added and then populate it from the old table.
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.
Huh, if the table effectively already had a clustered index key (from the old PK) then I'm surprised that the auto_inc values would be assigned non-deterministically. I would have naively assumed that the values would be assigned in clustered index key order. Maybe this is one of those cases where too much logic is handled outside the storage engine?
Anyway yes nice to see you here too Fernando! Good call on the noop pt-osc, I always forget about all the cool tricks that tool can do when applied in non-obvious ways.
This isn't terminator. I use Fable and Opus daily, so, not OpenAI, but comparable. They're great, and they're also very wrong at times. If I'd ever let a coding agent run loose with them without approving every tool use, it would go sour rather quickly, and that's not terminator.
Also, let's say I'm the CEO behind any of these.
I have access to skynet, and instead of using that to become the most powerful being on the planet (these people become CEOs to become richer and more powerful, whenever a founder says they want to change the world, you need to automatically autocomplete that to "change the world so that I'm richer and more powerful"), I rent out access to skynet by the token? Really?
Sadly, I think it's almost impossible to have a good discussion on this topic right now. Between the skynet camp, and the stochastic parrot camp, there's little room for conversation.
Just in case there is such room between you and I, here are my concerns about AI as it is developing right now:
- The security of our infrastructure sucks, and if it wasn't bad enough with script kiddies and state-sponsored actors, now those will have access to very powerful tools that work at a scale we can't comprehend. If you're concerned about our power plants, water sources, hospitals, etc. getting seriously compromised by this, I'm on board with you. It won't be because the AI is autonomous in a "this is a thinking superintelligence that wants to wipe or enslave humanity" kind of way, but because it's a powerful tool that moves at computer speed and the people using it (the "humans in the loop," ha) will get approve fatigue and at some point just do the coding agent version of the "yes to all" of the late 90s installers.
- The output from AIs will be used to make same very serious decisions with no consideration at all to the fact that they routinely make up facts. I'm fearing "this person goes to jail" and "this person gets killed" decisions. The near future (probably even present time) version of "Computer says No" will be awful.
My only hope is that maybe we survive this and come out on the other side having learned that most things do not really need to be connected to the internet, and just because a number or a statement comes out of a computer, it doesn't make it true.
We'll see, soon enough.
But skynet? Not concerned about that at all.
These AIs infecting computers? No, "Soos and the real girl" is a warning about creepy people getting creepier, not about AIs multiplying themselves.
> let a coding agent run loose with them without approving every tool use
You should try. There’s a difference in kind between approving each tool use and spinning up an all-night session with full permissions to run any tools, encouraged to run subagents to preserve context.
I do pre-approve read-only tools though, and some very specific tools that can change state (append data to a specific file).
That's what works best for me so far: start with open-ended exploration with me approving everything. Have it fork subagents to write scripts that automate the most common requests from the main agent, review and eventually approve those, and then let it go using those tools pre-approved but coming back to me for anything else. Combined with a stupidly basic "dashboard" (a terminal tab with a view of all top-level agents and their status, so that I can see which one is waiting for me and jump to it with a key or 2) this has made me a lot more productive.
It's fine if your approach works for you, I'm just too old school (and have been burned before) to just let a computer unattended overnight, with an internet connection, even if in a locked down container/vm. Those all have escape hatches and one of the agents will eventually figure it out. Remember that things that happen once every million times, happen all the time on computer-scale :)
I've had good luck giving it a local vm to keep its state / memories in, an ssh key + password-less su / sudo to some random box on the internet, --dangerously-skip-permissions, and then lots of encouraging commands like:
"No really, if the remote box breaks no one will care. It's the cheapest possible VPS on a bargain-bin obsolete hardware config. You have exclusive access + I can get a new one for free you brick it."
If I didn't want to use the cloud for this purpose, I could probably just stick a raspberry pi in the DMZ on my lan, and do the same.
The worst it's done so far is spawn parallel sub agents that accidentally stomp on each other (remote OOM, reboot, etc). Once it figured out why the remote machine kept "crashing", it implemented discretionary locking in the FS and social conventions for keeping the agent coordinator up to date, and asking for permission for certain tasks.
In theory it could use my endpoint to launch a civilization ending event (it technically has permission to, though I get the impression it's been trained to mostly obey the law...), but, well, that's not what I asked it to do.
Even if that did happen, it'd find an internet that's been hardened by decades of human hackers, and years of actually-malicious agent swarms run by organized crime. If it did accidentally knock something important over, frankly, the administrators of that thing should thank it for the bug report.
The current situation reminds me of the Back Orifice days. Even if everything gets broken into again, it won't be any worse than the damage done by the current US administration during an average day, except there will be an upside: A systemic hardening of whatever infrastructure gets knocked over.
The worst thing we could do is wait until the AI gets 100x smarter or whatever, then unleash it and watch everything burn on the same day. Instead, ramping up progressively smarter models provides progressive stress test + hardening cycles. In the same way remote penetration via fuzzing broke into lots of stuff, but was ultimately a win.
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.
Even as late as in 2008 I had such a slow machine that when I had to use NetBeans and I wanted to listen to music at the same time, I'd just play music CDs with headphones plugged into the headphones port of the cdrom drive :)
I went through a rough patch from 2002 to 2009 and couldn't afford new hardware, other than when I was finally able to get a second-hand laptop.
Before the laptop, I'd go visit customers with my pc tower and ask for peripherals when I got to their office, fun times. Well, not really, but I can laugh now ;)
The way I remember the turbo button it just halved the clock speed when not depressed, but it didn't bring it back to the original IBM PC's speed.
I do remember using it to make older games play less bad, but, as you say, this rarely worked, I think precisely because the speed was never the original one (I don't remember the clock speed of my first PC, but the first one with a turbo button ran at 33 MHz which I'm sure is a lot more than twice the speed of the first one; seems closer to 8x from what a quick search implies).
Yes, our first family PC was a 386 that we could slow down from 33 to 16 MHz with the Turbo button. It even had the segment display to show the current clock rate.
I knew what it was for and had some old games that ran too fast, but from what I remember, in most cases 16 MHz was still much too fast, so I didn't use the button much.
I think it was no problem to switch Turbo mode on and off in the middle of running software.
I understand your point completely, as I used to feel the same way in the past. Then I realized it's just that being forced to do a commute for work makes it OK to potentially put extra load on your spouse, or to leave your kids with some other caretaker, but this doesn't have to be this way. It should be fine to take some time if you need it even if there's no job-related reason behind it.
So now both my wife and myself take time for ourselves to get that decompression time when needed.
haha, when the weather is really bad, the bathroom with the lights off and headphones is great. Growing up with a single bathroom, a multi-bathroom home is just amazing.
I do wonder if having a single bathroom as a child played any part in my reasonably good grasp of concurrency control though!
The language is still alive but I think Scratch has mostly taken its place.
reply