peschkaj

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.

/me also waves from behind a CNC machine, pile of tools, jigs, etc

We intend to keep publishing data dumps and with the same regularity.

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.

Wat? My highest overall tax percentage was 32% when I made 300k as a single person.

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.