wilson090

excellent question - recently switched from turbopack after getting annoyed by build times. we saw them go from 6 mins to 2 mins

Are you on turbopack? It's available on Next 16 and just took our build times down from 6 minutes to 2 minutes

Inference is where they make the money they spend on training, so this feels unlikely. Perhaps this does not true for Mythos though

https://www.ycombinator.com/companies/pax-historia

you may be interested in https://www.paxhistoria.co/

The only mental gymnastics required are those to make this about "recent events"

This is extremely misleading. YC still backs Canadian founders (and other international founders). There must have been one too many painful experiences investing in companies based in Canada. Creating or converting to a US-based entity is a standard ask for most international founders who want to participate YC and I suppose something has changed such that Canada is no longer an exception to that.

Reminds me of Kurt Vonnegut - what a wonderful and absurd article

Love to see that people are able to create games without technical barriers. Being able to bring your ideas to life is such a powerful thing and it's great that more people can experience that

CreativeMode (S24) | https://creativemode.net | On-site - San Francisco, CA

CreativeMode is building Lovable for video game mods, starting with Minecraft. In our first three months, we built the most powerful no-code modding platform ever for Minecraft and created a double digit percentage of all mods ever released. We're building an entirely new category of gaming tools. Minecraft is only the beginning.

We're hiring a Founding Engineer who wants to build at the intersection of tech and gaming. Ideal candidates have a passion for the category and have experience building production-level LLM/AI applications or are killer full-stack engineers who can own product features end to end.

Ideally 3+ years of experience

Email me at wilson@creativemode.net with your resume and a short blurb on why you'd like to join the team.

How so? If you don't want AI bots reading information on the web, you don't actually want a free and open web. The reality of an open web is that such information is free and available for anyone.

This would probably make John Wilson's job a lot easier (https://en.wikipedia.org/wiki/How_To_with_John_Wilson)

The anti-LLM crowd on HN is far more cultish. I don't know why some developers insist on putting their head in the sand on this.

These studies profoundly miss the mark and were clearly written for engagement/to push a certain view. It's abundantly clear to any developer who has used LLMs that they are a useful tool and have turned the corner in terms of the value they're able to provide vs their limitations.

I've used instabase before which has had the same UX for years. What about benchmarks between the two on extraction performance?

Oh cool, I made something similar but for making a styled graphic rendering of a ride/run/trek: https://riderender.wilsonspearman.com/

also open-sourced: https://github.com/wilson090/ride-render

Relevant given the Stargate announcement

They're referring to Crusoe (crusoe.ai)

It's where the energy is for this project.

This is unfortunately paywalled but a good writeup on how the datacenter came to be: https://www.theinformation.com/articles/why-openai-and-oracl...

Agreed, the devil is in the detail for SRE functions, and the organizational details of how to leverage this framework are largely absent from this writeup. With so many teams struggling to get the organizational components right just for traditional SRE (due to budget constraints, internal politics, misunderstanding of SRE by leadership, etc), I'd imagine implementing the changes need to leverage the ideas in this writeup will be impossible for all but extremely deep-pocketed tech companies.

Nonetheless, lots of interesting concepts, so I would like to see a Google SRE handbook style writeup with more info that might be of more practical value.

It has potential to be incredible from a safety perspective and will save lives (I have an inreach but there are many people in the backcountry who don't, which makes sense given the cost and pricing model). I look forward to seeing the reliability data -- reliability is the one thing that kept me on inreach when the iOS sat feature came out.

It's the parking lot near Lincoln Blvd and Merchant Rd. If you come from Chrissy field, you wouldn't cut thru it, but my route is Arguello -> Washington -> Lincoln then through the parking lot onto the path by the battery onto the bridge

Would love to see this for the SF Bay Area - lots of great cycling around here and I'm unsatisfied with using Strava to create routes!

One of the most frustrating things for me with snapping to official paths is not being able to modify it for common workarounds (for instance, going across the Golden Gate bridge, everyone takes a shortcut through a parking lot, but every map routing platform I have used forces me to go the official route and messes up my nav)

Agents do not necessarily need to do the entire job of an SRE. They can deliver tremendous value by doing portions of the job. i.e. bringing in relevant data for a given alert or writing post-mortems. There are aspects of the role that are ripe for LLM-powered tools

While I agree that there are certainly cases of microservices being used in places they shouldn’t be, I have trouble imagining that monoliths are strictly better in every case. Do you have suggestions for running monoliths at scale?

What would you propose as an alternative to k8s?

Thanks! k8sgpt is great, it was one of our inspirations

Thanks! We've also been impressed with the performance of out-of-the-box LLMs on this use case. I think in part it is because k8s is a significantly more constrained problem-space than coding, and because of that we'll get to a much more complete solution with the existing state of LLMs than we would for a product like a general software engineer agent.

That is something we're working on -- good observability is a place where teams usually fall short and often the limiting factor to better incident response. We're working on logging integrations as a first step.

Yes, my understanding is that Onegrep is meant to provide context from your documentation and past incidents, which can be helpful when trying to solve an alert. We're focused on root-causing underlying infrastructure issues by actually looking into the logs/configurations/metrics.

Ah I actually did see beeps a while back. I haven't tried their product, but they seem to be similar to rootly/Onegrep in that they're working on on-call management/post-mortems