jssmith

I agree, I too found this barely readable.

Interestingly, ChatGPT was able to parse and explain it to me. I got a lot out of its presentation.

I get it. But I never would have until I built muscle memory for the keyboard shortcut.

I see JSON parse errors on occasion when using OpeanAI structured outputs that resolve upon retry. It seems it’s giving instructions to the LLM but validation is still up to the caller. Wondering if others see this too.

We've been focusing on indexing but query rewrites are probably next.

It looks like LLMs can do a pretty good job at generating ideas, particularly if you prompt them right.

After that, you have to: 1/ make sure that the SQL produces the same results, 2/ see what the query planner will actually do with it, 3/ see whether it improves performance.

As you point out, the data makes a difference, so you need production data statistics, at a minimum, to do this well.

Right. Why build another MCP server for Postgres?

There's a lot of value in just getting a database connection. But the LLMs hit limits pretty quickly when it comes to index tuning, etc.

Classical algorithms still have their place.

Confused about the new US tariffs? We built an interactive US Tariff Calculator—a simple tool to help you instantly calculate the new tariffs per country.

Yes, but it is more restrictive, e.g., it is not Turing complete. I’m not sure whether this directly addresses Spectre risks though.

An analysis of Spectre and software isolation is here:

https://arxiv.org/abs/1902.05178

Fair enough. American companies (and people) definitely have a home bias. I guess to be constructive, I would suggest that perhaps there are parallels in your country.

I don't remember exactly how it broke the first time, but the cognitive overhead shows up in various places. E.g., start a new project, create a branch, then merge back to master... oh wait, it's main now? But then I'm back to an old project, or another person's project, so let me look up what name I need to be using, etc...

I want to share my own reactions to the name change since this is a really interesting topic. For context, I'm an African American, so many of my ancestors were slaves.

  - The first time it occurred to me that "master" in this context could offend anyone was when GitHub changed the name (and broke my workflow).
  - My immediate reaction was, "this change is by white people for white people," where "white" means anyone who isn't black.
  - My next reaction was, "they may be changing the name for the wrong reasons, but the change is brilliant."

Let me explain a little more. Whether motivated purely by virtue signaling or by more genuine intentions, changing the name doesn't fix any of the problems that black people face. The article explains this well.

What's powerful about this name change is that it pushes us to alter a habit, in my case one embedded deeply in my fingers, something that I do every day without realizing that I'm doing it. Thus it is a useful reminder of the implicit bias that contributes to the lack of diversity in tech. Never mind that the old name was harmless, the change brings repeated awareness to an important topic, and it reaches a the developer community in a targeted way.

So, next time you are annoyed that you have to fix a script or you accidentally type master when you needed to type main, please just take a deep breath, change the name, and remember to reflect upon whether you have are subconscious habits or biases that work against diversity in tech.

Yes, the idea is that the cloud provider should offer something like this. We intercepted system calls to simulate what it would look like.

Thanks for sharing your writeup and the potential use cases therein.

We've been building an experimental shared file system that specifically targets the FaaS setting. It supports SQLite and gets big performance gains over NFS/EFS, especially on read-mostly workloads, due to improved local caching and lock elision. See: https://arxiv.org/abs/2009.09845

Would any of these be useful for working with Johns Hopkins Covid-19 data? There are some web interfaces but analyzing and visualizing with Python would be more flexible.

(https://data.humdata.org/dataset/novel-coronavirus-2019-ncov...).

This capability is compelling from a public-health standpoint but has serious privacy implications. It looks like every phone shares a unique id, but encrypts it in a frequently rotating way, using a public key provided by a government authority.

This raises a few questions for me: - Is an entirely decentralized solution to this problem possible? - Aside from placing trust in the government, are the privacy protections adequate?

If you’ve used some heavyweight framework then performance will probably be hard to add later. If you wrote the code yourself then I’m with Knuth, it’s not a big deal to optimize it later and that’s a much better way to go.

I’ve found the following rubric helpful for building distributed systems: 1/ correctness, 2/ reliability, 3/ performance. Credit: CochroachDB team.

One startup that’s working on this is unitQ: https://www.unitq.com

I think this has been the case for the case for the past 20 years, probably longer, though I'm optimistic that improvement is possible. E.g., perhaps serverless computing is inefficient today but it could help improve hardware utilization.

> Many researchers are now arguing that we should, more generally, move away from using statistics to make all-or-none decisions and instead use them for "estimation". In other words, instead of asking whether an effect is null or not, we should ask how big the effect is likely to be given the data.

I couldn’t agree more with this statement, and even moreso in a business setting than in research. It’s just so easy to get caught up in statistical significance and lose perspective on practical significance. I’ve found confidence intervals most informative and easy to understand.

This view on sharing hardware seems too pessimistic to me. Strong isolation should be achievable when it is the design objective and and priority.

On the end-user/device side, JavaScript has proven that sharing hardware with untrusted code is just too valuable to give up, and a similar dynamic continues to play out in the cloud.

I'm also happy whenever a headline brings attention to these types of problems because I believe we can fix them.

As a command-line tool it could serve as a more powerful replacement for unix utilities that I often use for simple analysis jobs: sort, uniq, wc, awk, sometimes cut and sed. I'm going to give it a try.

It looks like textql loads everything into an in-memory SQLite instance, whereas I'd really like to see an approach that uses the SQLite's virtual table mechanism (https://sqlite.org/vtab.html), which would avoid the loading step and perhaps make streaming processing possible.

This is a really interesting comparison. Plumbing jobs have a reputation for high pay, as do jobs in tech. Is hooking up APIs as miserable as fixing faucets? Maybe, but I really think that self-reinforcing cultural patterns play a big role in perpetuating these gender imbalances: women opt out because of culture that results when there are few women.

The women with the most other options are perhaps most likely to go elsewhere. Some of the men who have the most options may be right behind them.

One reason why we should care about culture at other companies is because it drags down the appeal of our industry. When talented people with lots of options choose a career outside of tech it hurts all of us.

Oracle does pretty well running OLTP and analytics workloads concurrently against the same schema. While I don't generally recommend doing so, you can fire off massive scans or complex joins against a production system doing thousands of transactions per second and it handles it just fine.

In my view, one reason that we don't see huge demand for this combination is that the schema that makes sense for analytics is often different from that which makes sense for the online system.

Great observation. So if we have to choose between diversity as a target and as a measure, which would be better ?

I wouldn't take the comparison to affirmative action too far here. Our startup / VC ecosystem exists to drive radical progress and to achieve success where it seems unlikely. So let's go for it and get creative.

Somebody isn't keeping an eye on the calendar... licenses need to be tracked and renewed, just like domain registrations and SSL certificates, otherwise things break.

Unfortunately, I've seen this before, more than once. I've come to believe that a high-availability product should keep the places where human error can creep in to an absolute minimum. That means no artificial breaking points.

Ask vendors whether their products are susceptible to this failure mode and factor the answer into your purchasing decisions. Also recognize that if they want to they can give you a perpetual license file even if business terms mandate renewal.

I searched for years for the right fit in earplugs, purchasing perhaps a dozen types along the way. In hindsight I would suggest purchasing a variety pack. I think it would have saved me a lot of time and money.

Something like: http://www.earplugstore.com/foearpltrpa2.html

My personal favorites: 3M E-A-R Classic Soft Earplugs

You make "it's not Facebook" a key part of your value proposition. This was the case for Snap early on, and I believe it's a big part of the reason why they got so far. Their users needed a social network separate from their parents, and they had been trained to fear long-term memory upon which Facebook had built their product and their business model. WhatsApp was also successful in warding off FB Messenger's efforts to clone it, in large part because it offered independence and a very un-Facebooklike product experience.

Facebook has shown an impressive flexibility and willingness to pay the costs of making big changes when they need to, e.g., acquiring WhatsApp or shifting their product toward Stories. Still, a startup go a really long way by building a product that carries "not Facebook" as a key value proposition.

My guess is that the contract under scrutiny to the RFP COMM-16-BC-2020. Here are the services to be provided:

  - Research and Data Analytics
  - Strategic Planning, Program Development, and Integration
  - Communications Support for Decennial Census Operations and Other Programs
  - Field Recruitment Advertising and Communications
  - Traditional Advertising and Media Buying
  - Digital Advertising and Other Communications Technologies
  - Social Media
  - Public Relations
  - Communications Planning and Materials for the Partnership Program
  - Statistics in Schools Program
  - Website Development and Digital Engagement
  - Rapid Response Activities
  - Project and Financial Management
  - Stakeholders Relations
  - Communications Support for the 2020 Census Data Dissemination

The scope here is pretty large and it includes advertising, etc., so one can see how it might cost hundreds of millions. It isn't just about setting up a database and running a web site.

Full document is here:

ftp://ftp.census.gov/about/business-opportunities/2020-comm-final-rfp-1-21-16.pdf

Ugh, lockout must be pretty frustrating. Receiving one message could be worth as much as sending 1000 messages when valued by conversion to the spam end-goal. It's also a less obvious technique and one that's more difficult to block. Clearly the algorithm is not as precise as it should be, but I'm sure this mechanism is preventing a lot of abuse even though it blocks some normal use.

Friendster definitely failed because they couldn't pull off scale. I was CTO of the Tagged social network at the time and the issue loomed large during our 2005 fundraising. Investors had seen $50m go down the drain when Friendster got slow. Despite network effects, users moved over to products that were up and running (mostly MySpace but also hi5, etc.).

I seem to recall that the Friendster team had more than one aborted rewrite before they got it right, and by then it was too late. Scaling social networks required a different bag of tricks than was popular at the time (e.g., database replication was well accepted as a best practice, but sharding worked much better). Talented people could still get it wrong.

Still, social networking illustrates how failing to scale is rare, and should practically never be the concern early on. Almost every social network that gained traction struggled to scale at times, but the vast majority of them overcame their challenges.

We poured sweat and tears and many sleepless nights into scaling the Tagged back-end from 10 machines to over 1,000, over time serving hundreds of millions of users. It was a tremendous amount of work, much more than building the initial product, and I don't think there's much we could have done early on to make later scaling easier.

More on the story: http://highscalability.com/blog/2011/8/8/tagged-architecture...