SigmundA

iPad used to be able to act as a HomeKit hub before Matter support, it was phased out starting in iOS 16 and fully removed this year.

Not bad, think I still prefer that their visual cortex was more advanced such that they could easily perceive multiple perspectives (necker cubes) and maybe even higher dimensions but they had a "crucifixion glitch" such that too much euclidean geometry in the visual field of view caused seizures which doesn't normally occur in nature.

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.

Best explanation for vampires not liking crosses I have ever seen. I always enjoy vampires that are explained scientifically for some reason in fiction, its like some sort of challenge and they usually avoid the whole dislike of crosses, not here, thought it was a decent attempt along with many other ideas in the book, very enjoyable to me.

MSSQL (Clustered Indexes) and Oracle (Index Organized Tables) among others let you chose because there are advantages and disadvantages for different situations.

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.

So maybe it should have two different undo files so both can be run side by side?

I think this might not be clear on the issue, it broke vim's undo file, as in it deleted it and replaced it with Neovims version.

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

I have memories of supporting a Netware network with a custom Foxpro app used by a bunch of telemarketers in the mid 90's.

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.

I wonder if the Trump T2 phone will get this chip.

I much prefer Bryson City to Gatlinburg, and you can technically go into the park right outside Bryson City at Deep Creek, and even hike to Clingmans dome.

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.

MSSQL can handle 32k open connections no need to run a pooler in front of it, can PG do 32k connections and a process for each?

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.

Interesting I have definitely used the distinction between null and empty string quite a bit in MSSQL and matches most programming languages.

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.

Each PG connection being a whole process does not scale like MSSQL that uses a thread per connection which has a max of 32k per instance.

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.