Learning how modern AI's respond immediately made me think about how Rorschach was communicating with the crew and how current LLM AI's might be considered intelligent while not conscious.

https://en.wikipedia.org/wiki/Blindsight_(Watts_novel)#Consc...

This helped explained their downfall with man creating euclidean geometry everywhere and was taken advantage of when they where brought back as they where very good at certain tasks while also requiring anti seizure drugs which kept them in control.

Not having true clustered indexes in PG is something I miss coming from MSSQL, it helps performance when the majority of access is always primary index avoid indirection from index lookup then tuple lookup and it also saves space if its the only index.

Just by trying Neovim you can lose your vim undo file.

When there was application error the source code would pop up in dialog maybe a some sort of debugger and the end users would just type a bunch of crap in trying to get out of it and hit enter and save the changes and corrupt the app for everyone and it would have to be restored from backup.

Pretty sure it was Foxpro or maybe dbase, definitely wasn't MS Access as it was still a dos based client.

Very different idea about app security back then, was really nice to developed the db, GUI front end and printable reports all in single runtime though.

Gatlinburg is a tourist madhouse while Bryson City is a great little town and you can drive over to Cherokee if you want more and get into the main part of the park and over to Gatlinburg should you so desire.

Road to nowhere is always fun to visit, kids always laugh at the graffiti and like the creepy tunnel while the hikes around are beautiful.

https://bugs.webkit.org/show_bug.cgi?id=277286

MSSQL shares cached query plans between connections including jitted code, PG cannot do that and the changes needed to make the plans cross process portable would be extensive while sharing between threads is just normal code sharing between threads.

MSSQL has its own task scheduler with the ability to kill etc, its like its own OS internally in that respect but yes there is no memory protection there for unmanaged code.

It doesn't really have unsafe extensions other than it is possible to create extended stored procedures which could do bad things, very frowned upon. If you were concerned about that you would run that database in its own instance (process).

https://learn.microsoft.com/en-us/sql/relational-databases/s...

https://learn.microsoft.com/en-us/sql/t-sql/language-element...

https://learn.microsoft.com/en-us/sql/relational-databases/e...

>I'm thinking the buffer cache and locks and WAL coordination are just as fast - it's just mmap'd SHM into each process.

Plan caches contain pointers to executable code and sometimes jitted code, this cannot be just shared to another process with a different address space and work, this is code not data, to transport between processes it needs to be serialized in a way that is not tied to process memory including things like ASR, certainly doable but since it wasn't designed that way much needs to be changed vs just sharing between threads.

https://en.wikipedia.org/wiki/Position-independent_code

Another issue that used to exist was Oracle table name were limited to like 12 characters or something so I have seen horrible abbreviated table names to fit in the Oracle limitation even in other DB's due to some systems being able to run on both MSSQL and Oracle even though SQL Server has a 255 char limit for table names.

There are no need for connection poolers in front of MSSQL although it is normal to pool connections in the client application which may hold hundreds open typically in a web server.

This also allows MSSQL to more easily share cached query plans between connections since its just sharing executable code between threads.

For PG to do plan caching it would need to serialize the plan between processes and that would require some significant work since it was never designed that way.

PG has it obvious unix roots using processes instead of threads, MSSQL coming from Windows where new process are expensive and there was no real fork, but threads are cheap uses that approach instead.

There are other relational databases that have both kinds of storage engines and some use both on the same table (row based insert with column based migration and secondary column store indexes: https://learn.microsoft.com/en-us/sql/relational-databases/i...

Just like you can have b-tree based table storage vs heap in the case of index organized tables / clustered indexes (which pg doesn't have) you can choose column based instead the logical data model is still the same relational model.

Modern cars will auto brake if sensors detect what it thinks is an imminent collision regardless of accelerator position: https://en.wikipedia.org/wiki/Automated_emergency_braking_sy...

Traction control systems will cut power if wheel slip is detected again regardless of accelerator position: https://en.wikipedia.org/wiki/Traction_control_system

FSD is obviously very different than normal cruise control and I cannot see an argument why a system that knows its heading down a dead end street at more than double the posted speed limit would allow such and accelerator override and not apply automatic emergency braking, it makes no sense, that serves no purpose while leading to a tragic outcome.