came across a related article recently that explored the economics and physics of airships [1]. seems like a monumental undertaking to actually bring to market but the principles seem sound
Agreed, "real pain" is a subjective/vague term and even crypto is a broad term. My intended use here is to describe solutions that are more grounded/integrated into reality vs. more grounded in a fantasy of how the world works. It is hard to describe well though and if you keep unrolling most perceptions of reality are subjective
Agreed, but IMO it's their job to do stuff like this (and prob unrealistic to expect a world where it doesn't exist). I'd rather see a higher percentage of marketing for things that have more real value vs. less
Of course - there will always be investors/influencers pushing narratives to hype their bets. IMO everyone is better off when the hype is grounded in solving real pain points, which the AI projects I've seen seem to be closer to than most of the crypto projects I've seen.
Certainly there are plenty of grifters in AI too (as with any gold rush) and many AI efforts will fizzle out. But it seems there is more real value being created here than in crypto, which is the main thing I'm excited about and hope to see more of
Even knowing this is partly motivated by branding/marketing, it's great to see a16z getting more aligned with solving real pain points (vs crypto and churning out shallow media in recent years). Hope they can keep it up and hopefully more "thought leaders"/VCs follow suit. Best of luck.
> You will not use the Llama Materials or any output or results of the Llama Materials to improve any other large language model (excluding Llama 2 or derivative works thereof). [0]
With regards to The Scientific Method (and other ideas mentioned), I found some of David Deutsch's work thought-provoking. Namely, the idea that deductive reasoning is more effective than inductive when seeking new hypotheses. The Beginning of Infinity is a decent starting place [0]. Also related to some of Nassim Taleb's work.
As a recent addition, I've been impressed with Kevin P. Murphy's Probabilistic Machine Learning: An Introduction (2022)[1] and Advanced Topics (2023)[2].
Thanks for the response. I do recall hitting some product limitations (a webhooks "beta" that we tried to use but hit a blocker). Reflecting more, I don't recall the supporting details specifically enough though. Edited original post and apologies for the added noise.
"The situation becomes interesting when the vast majority of your data sits in a single logical database. In this case you have two primary issues to consider. One is the choice of programming language: SQL versus your application language. The other is where the code runs, SQL at the database, or in memory.
SQL makes some things easy, but other things more difficult. Some people find SQL easy to work with, others find it horribly cryptic. The teams personal comfort is a big issue here. I would suggest that if you go the route of putting a lot of logic in SQL, don't expect to be portable - use all of your vendors extensions and cheerfully bind yourself to their technology. If you want portability keep logic out of SQL."
I also had a tough time working w/ an app someone else built on Supabase. We kept bumping up against what felt like "I know feature X exists in postgres, but it's 'coming soon' in Supabase." IIRC the blocker was specific to the trigger/edge function behavior.
However after reflecting more, I don't remember enough to make a detailed case. Perhaps the issue was with our use of the product.
"WearCam has been an experiment in connectivity, starting early 1994, running on and off until September 15, 1996 (shut down when I went to ICIP 96 in Lousanne, due to poor net connection from there). After the conference, I decided that extensive revisions were in order: with further development of the pencigraphic image compositing algorithm that assembles the images transmitted from my wearable computer system to the base station on the roof of building 54. The hope is to have near-realtime performance using a 64-processor system."
Open communication is great when there are incidents, but even better is having no incidents. (of course there are nuances depending on specific context)
> It’s simply not economically viable to continue adding functionality to a product that does not generate any revenue.
I'd gently push back on this. If the primary purpose of the open source component of an open core project is to acquire new free users (top of funnel for paid users), then it provides some value. Any work spent keeping the open source experience good is essentially marketing spend and may make sense depending on the ROI. Agreed the incentive is to eventually get those users converted to paid users, but that's not inherently a bad thing IMO. Acknowledge there are better and worse ways to go about incentivizing users to convert to paid.
Overall I enjoyed the post. The latter half felt a bit less concise but intro was strong.
[1] https://www.elidourado.com/p/cargo-airships