Well, I mean you could use an adze or a froe. Axes are really common in green woodworking (chair making) and they’re great for getting wood to split along the grain.
Yup! Mostly legal. We maintain a legal guidance page[1] covering what you can and can't do with the data. I assume our lawyers have been involved, but what do I know?
I use X410 and run tools from inside of WSL2 by exporting the display. Works well for Emacs, JetBrains Rider, and every other GUI application I've tried so far.
My install seems to have no ads at all (including on the Start Menu) and I am using Win 10 Pro that I installed straight from the Windows download page. Maybe I don't get ads because I'm on the Insiders Slow Ring.
I run Ubuntu on a 5510 and I love it. I get between 5 and 7 hours of battery life with it. Using the NVidia card will kill the battery, so be careful and make sure you set up Bumblebee/BBSwitch on Linux (or the NVidia settings on Windows). Otherwise, it's a great machine. I picked up the 32GB model with a 1TB NVMe drive and QHD+ display.
However, it is a bit too large for a bike commuter and I'll be selling it on eBay shortly.
It's just the relational engine for now, no SSIS, SSAS, or SSRS. If you want to see more capabilities on Linux, I'd open a Connect item or search for an existing one and share it back here so people can vote.
Are you referring to the i7-6700HQ that was released in 2015? The CPU that's present in the 15" Retina MacBook Pro? Or is there a different CPU that nobody else is privy to?
I think we're in agreement writing applications in the database isn't a good idea.
By "empirical proof", I mean that I have never seen anyone conclusively prove that switching data access from stored procedures to ad hoc SQL through an application was the cause of performance improvement. I've seen proof that removing complex application logic from the database fixed a problem, or that better indexing improved performance, but I've never seen anyone prove that removing stored procedures alone fixed the problem.
Further, there's nothing in your proposed solution of scaling out with readable replicas that precludes the use of stored procedures for data access. As a huge fan of both databases and separation of concerns, stored procedures make tremendous sense. They let a domain expert tune the database as needed. Even going so far as allowing that expert to re-write queries, provide optimizer hints, or even change the physical data model for better performance without ever changing application code.
Although I may or may not be competent, I have scaled "stuff" in a database. But I do appreciate you getting a vague ad hominem into the first sentence. Bravo.
The typical bottlenecks that I found were almost always IO - either through crappy storage, crappy indexing, or some combination of the two. Modern databases typically aren't bottlenecked by the lock manager.
I'd also agree that moving work out to a NoSQL database is particularly tricky. For three years I maintained the .NET Riak client and helped developers make better decisions when they were considering moving away from an RDMBS.
I've yet to see empirical proof that stored procedures don't scale well. If you write an application in your SQL dialect of choice, that likely won't scale well, but putting data access behind an API should scale well no matter if that API is in Rails, Spring, or a stored procedure.
If you're using Hyper-V, you get an unlimited number of guests if you've purchased Windows Server Enterprise Edition. Last I checked, it's not even that expensive of an upgrade.
I don't know if they've fixed the issue, but the Box client used to spike CPU at 100% on OS X. This would occur when you have a folder hierarchy with a lot of small files in it.
It turned out that their client was enumerating folders and files looking for changed data rather than hooking into the OS X file system notifications. We really liked it for the corporate account since it's possible to selectively grant outside parties access to files/folders.
I think we should commission such a study. Those of us with English degrees will be perfectly suited to conducting this survey and delivering the results in epic poem format.
MongoDB's journal is another collection that only syncs to disk 10 times a second. It's not a true journal like a write-ahead log. You can force that collection to fsync, but... yeah, I get get stupendous performance using a cheap RAID controller on commodity hardware with an old and busted relational database. Hooray for 40 years of technology!
You are correct - any database with the entire dataset in memory will be incredibly fast. SQL Server bypasses the Windows file system cache and will aggressively manage memory to keep frequently accessed data pages resident in RAM. The read/write performance is what you would expect for a database with fine-graned lock management - when you have to go to disk things get slower, otherwise I/O is only limited by RAM and the overhead of lock management.