bodecker's comments

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

[1] https://www.elidourado.com/p/cargo-airships

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

Congrats to the folks involved.

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]

Interesting

[0] https://ai.meta.com/resources/models-and-libraries/llama-dow...

I assume comments like these, "GPT-4: 8 x 220B experts trained with different data/task distributions and 16-iter inference."

https://twitter.com/soumithchintala/status/16712671501017210... https://archive.li/rfFlW

I'm not sure the most canonical paper on mixture of experts but here's one possible:

https://arxiv.org/pdf/1701.06538.pdf

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.

[0] https://www.amazon.com/dp/0143121359

Related thread "OpenAI's plans according to Sam Altman removed at OpenAI's request": https://news.ycombinator.com/item?id=36177895

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].

[1] https://probml.github.io/pml-book/book1.html

[2] https://probml.github.io/pml-book/book2.html

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.

Also reminds me of this Martin Fowler post [0]:

"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."

[0] https://martinfowler.com/articles/dblogic.html

(Significantly edited after discussion)

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.

nifty. neat linked astrophotography blog: http://wondroussky.blogspot.com/

obligatory Steve Mann reference: http://wearcam.org/myviews4.html

"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."

also narrative (and of course related products like glass, spectacles, etc) - http://getnarrative.com/ - (2014) https://www.cnet.com/reviews/narrative-clip-review/ - (2016) https://www.fastcompany.com/3064785/why-some-wearable-camera...

unclear how humane will toe the privacy line - https://techcrunch.com/2023/03/08/humane-the-secretive-ai-st...

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.

> Ship daily

This is great advice, but when it's not possible to ship daily, I find that even just committing once a day is a good micro-goal to keep projects moving. The GitHub streaks feature can help motivate you too.

This is fascinating! Any idea how it is implemented? Guessing it's using some open source search engine like Elasticsearch to build the indices/compute relevance in a centralized manner. Would it be possible to leverage the distributed nature of TOR to create a completely P2P/distributed version of this search engine? Relevance features like TF/IDF might be a bit challenging to implement, but it seems like it would be possible!

Fei Fei Li has some great quotes near the end (starting around 31:10):

"I find it very hard to convince women and underrepresented minorities to work in AI."

“We are not sending the right messages to attract people of all walks of life - we tend to just celebrate geekiness, nerdiness, but when you have an ambitious young woman coming into our department or into the AI lab... if we present ourselves just as geeks loving to do geeky things, we’re missing a huge demography..."

“We're missing a huge opportunity attracting diversity because we're not talking enough or thinking enough of humanistic missions in AI."

I have a little sister who often wonders whether she should keep studying engineering because of things like this.