As a customer of Konfig, I am super bummed about this. I think we may even have been their first customer (referenced in the init commit). Dylan and Anh-Tuan solved a number of real problems for us, and they did it spectacularly. They essentially provided a one-stop-shop for generated SDKs and beautiful hosted docs/tutorials that would call our API and immediately allow users to start playing with real data. Prior to Konfig, we were hand-writing a hodgepodge of SDKs to wrap our API and using ReadMe to host the docs (which never quite worked interactively with our API due to request signing that we require on our API).
Tons of respect for these guys and I wish they'd found a way to make it work.
Also, for anyone finding themselves in a similar situation as Konfig (a product that (some? most? all?) customers love, but revenue not scaling as needed), please consider charging more. We probably would have paid 2-3x what Konfig was charging us and more as we grow, but they never asked and never built in any usage-based cost scaling (like $X/month/SDK, $Y/month/demo, etc).
I was looking forward to that as well, but Siri refuses to read ChatGPT's responses to me...which makes it substantially less useful. It's just as frustrating as being told "sorry, you'll have to unlock your phone if you want me to play something on youtube music". Let's hope they iterate, I guess?
One of the biggest contributors to pollinator decline is loss of habitat for native bees. Most bees are actually solitary (don’t live in hives) and live in little crannies or holes in the ground.
One of the coolest things I’ve come across recently is the idea of “bee homes” that you can put in your garden to provide habitat for bees. I’ve bought a couple beautiful wooden units from Scopa and we just got our first bee resident this week!
Thank you, that was a fascinating talk and I learned quite a bit.
However, it did not provide a convincing argument as to why LLMs cannot be a part of a "doomer" AI. In fact, I got the opposite vibe from Andrej explaining expected future developments. The whole section on System 2 thinking sounds like a layer constructed around dumb LLMs that would result in vastly improved and more generalizable intelligence.
I agree that just scaling the size of LLMs is probably not sufficient for AGI...but that just seems like one relatively minor piece of all the possible ways it might be achieved.
As much as I can appreciate Doctorow’s exasperation, I find his dismissal of the doomer vs accelerationist debate rather pithy. I would love to be convinced that “dumb” LLMs can never gain sentience (or be finagled into sentience with a wrapper).
What is the actual argument for why that’s true?
(I realize you could turn the question around and ask why I think it might be possible in the first place, but I feel like my expectations have been blown out of the water so regularly and so increasingly frequently that I can’t default to being a naysayer anymore)
Sure, but it would be more constructive to explain why it's wrong. GP's comment has some interesting ideas and it would be better to directly refute them than just claiming they're "factually wrong".
Kable has been super helpful for my company so far! Our billing is pretty complicated because it's usage-based and we're customizing pricing for every single customer at this point.
The integration with Kable was very simple, took like 15 minutes to get a basic implementation working. It fires "billing events" automatically and then these can be applied to custom pricing options for every customer.
On the face of it, no, it doesn't sound revolutionary. "Just switch to renewables" is something I've been hearing for 20 years and I never believed it could work until I read this book.
The book is quite thorough in laying out all the challenges (eg, handling variable production from renewables, how to get buy-in from existing fossil fuel stakeholders, how to rearchitect the grid from hub-and-spoke to something more like the internet, how to finance the massive upfront cost in a way that will actually save money, etc) and presents realistic solutions for each.
Please don't take my word for it, just pick up a copy and read it.
It's not really that electricity is more efficient (is IS more efficient in most cases, but a key point of the book is that we can't "efficiency" our way out of the climate crisis). It's that as long as the generation of electricity is clean, the use of it is also clean. We already have clean ways of generating electricity that are cost-competitive with fossil fuels, and by scaling up production it will actually end up massively cheaper than fossil fuels. But there is a high upfront cost to switching, so financing the switch is one of the biggest challenges.
The book is quite thorough in laying out all the challenges (eg, handling variable production from renewables, how to get buy-in from existing fossil fuel stakeholders, etc) and presents realistic solutions for each. I recommend you pick up a copy and read it!
Yeah, that's basically the point of the book. Acknowledging that our dependence on fossil fuels is hard to break, but outlining an actually realistic plan for doing so.
While on the topic of green energy, I recently started reading Electrify by Saul Griffith [0] which outlines a pretty comprehensive plan for addressing climate change with a broad shift to "electric everything". The summary is that by investing massively in renewables and electrification NOW, it we can solve climate change and also reduce the cost of living for everyone everywhere (not to mention the bonus of not irreversibly altering the climate).
If you are at all concerned about the future of our planet, IMO this is required reading!
Seems like a strange bit of feedback to me. My company uses Django as the backend for our REST API and it's simply phenomenal. Django isn't a complete solution out of the box, but that's why things like Django REST Framework [0] exist. It supports JSON-based views and has an excellent serialization layer that can map directly to the ORM models.
This setup does NOT help with serving our frontend app, but we're using React for that anyway and I'm not sure I'd want our frontend so tightly coupled to the backend.
The fact that Django is mature and extremely stable between versions is a huge selling point for us. I'm not interested in making sweeping changes to our backend just because someone invented a new paradigm that may or may not be helpful to our app (eg, GraphQL).
That said, rendering HTML templates server-side does feel pretty archaic these days. I think it would be great for Django to take a more API-centric approach for a default installation. I can imagine that anybody coming from the JS world would feel totally out of place in terms of how Django works out of the box.
Just because it often works doesn't mean it's a good idea. Updating a single package is officially unsupported [0] and it's burned me personally on a number of occasions.
Here are some "sleepers" that people have built over the years [1,2,3]
[0] https://thelaserhive.com/product-category/powermac-g4-conver...
[1] https://old.reddit.com/r/sleeperbattlestations/comments/1gva...
[2] https://old.reddit.com/r/sleeperbattlestations/comments/1871...
[3] https://old.reddit.com/r/sleeperbattlestations/comments/t7tz...