> Suppose a person retrives cold data from another Object Storage protocol rather than S3. This is no longer a "Lakebase", so we have to come up with a different name to avoid confusion.
I've never seen "lake" or adjacent terminology refer to S3 specifically like that vs other object storage. A data lake on Ceph would still be a data lake.
(My quibble would be that "lake" often refers to inconsistent or unstructured, and itself has always been a bit handwavy compared to "warehouse," whereas this is very structured data on object storage.)
Maybe I’m wrong, but AFAICT this is block (page) storage backed by S3, tuned for Postgres with some paxos-linked storage/caching servers sitting in front? Sounds good, but I’m not sure “lake” or “warehouse” is a word I’d choose… much closer to Litestream-with-reads, or the somewhat-famous “I ran out of RAM so I downloaded some more” blog article.
> What is the business model of open weight AI? I don't think there is any. At best it can serve as an advertisement for the more advanced models you sell.
I don't think local will necessarily be open-weight. And then it's not that different from personal computing: you're giving up the big lucrative corporate mainframe, thin-client model for "sell copies to a ton of individuals."
So it'd be someone else (an Apple, or the next-year equivalent of 1976 Apple) who'd start eating into that. There are a few on-device things today, but not for much heavy lifting. At first it's a toy, could maybe become more realized in a still-toy-like basis like a fully-local Alexa; in the future it grows until it eats 80-90% of the OpenAI/Anthropic use cases.
Incumbents would always rather you pay a subscription or per-use forever, but if the market looks big enough, someone will try to disrupt it.
Compute has gone back and forth from mainframe/thin client to fat client a few times already. LLMs will probably follow at some point but I think it's going to take a long time.
The cost to transmit text is basically free and instantaneous. The rent (i.e. a GPU in a data center) vs buy is going to favor rent until buy is a trivial expense. Like 50-100 range.
Even then a LLM that just works is easier than dealing with your own
Storage has moved back and forth but I don't thnk compute has ever really gone back to thin client. Even Gmail, Google Docs, etc are running a buttload of javascript on the user device. Various attempts at avoiding that (remote .NET or JVM stuff on early "smart-ish" phones) crashed and burned.
Video game streaming is the closest thing, and it's never really taken off. (And this, IMO, is a good comparison because it's a pretty similar magnitude up-front-cost, $500-$4000.)
Once the local-AI-is-good-enough (Sonnet level for a lot of basic tasks, say) for a $1k up-front investment the appeal of having something that can chew on various tasks 24/7 w/o rate limits, API token budget charge concerns, etc, is going to unlock a lot of new approaches to problems. Essentially more fully-baked line-of-business OpenClaw-type things. Or the smart home automation bot of Siri's dreams. You can more easily make that all private and secure when all the compute is local: don't give any outside network access. Push data into the sandbox periodically via boring old scripts-on-cronjobs, vs giving any sort of "agentic" harness external access. Have extremely limited data structures for getting output/instructions back out. I'd never want to pass info about my personal finances into a third party remote model; but I'd let a local one crunch numbers on it.
Even if you need Opus/Mythos/whatever level for certain tasks, if 95% of everything else you'd pay Anthropic or OpenAI for can now be done on things you own w/o third party risk... what does that do to the investment appeal of building better AI appliances to sell end users vs building better centralized models?
I think "what if today's LLM performance, but running entirely under your control and your own hardware" opens up a LOT of interesting functionality. Crowdsource the whole world's creativity to figure out what to do with it, vs waiting for product managers and engineers at 3 individual companies to release features.
There was a time where people ran software on their computer with limited connectivity. Late 90s/early 2000s most of what you did was running locally on your machine. Your emails would be downloaded and there'd be a shared drive but otherwise all local.
Anyways, who's spending $1k for a LLM machine when they can spend $20 (or 0) on a subscription? And who's having an LLM crunching away 24/7 anyways? Anyone who is going to do something like that probably wants a cutting edge model.
It'll (probably) get to a point where the hardware is cheap enough and advancement levels off. But we're a ways from that and even then when a data center is 20ms away why not offload heavy compute that's mostly text in text out.
Except that buy is a trivial expense because the hardware has been bought already. You've got a whole lot of iGPU and dGPU silicon that's currently sitting idle as part of consumer devices and could be working on local AI inference under the end user's control.
> Synthesis problems and time pressure don't feel fair together.
If you really want to grade the students its fair to put very hard problems on the exam to separate out mastery from merely very good understanding or recital.
Hard problems introduce noise to the grades. A student who gets a hard problem right could be good or lucky. In order to grade the students properly, you need multiple problems of similar difficulty. If you have both ordinary and difficult problems in the exam, it's probably long enough that it should take the entire day.
Undergraduate exams tend to be short. Which means that a perfect grade should be interpreted as "meets the expectations".
Which means that a perfect grade should be interpreted as "meets the expectations".
None of the mathematics exams I wrote during undergrad at Waterloo (as a math major) would fit that description. Nearly every single one of them had midterm grades with unimodal distributions centred below 70%, tending toward 60%. Typically, only 1-5 people in the class (of 100-200) would score a perfect grade. In upper year pure mathematics courses it was common to not have any perfect grades (in a class of about 20-30).
Mathematics is notorious for exams like that. But if you look at the reasons why people fail to get a perfect grade at undergraduate level, it's almost always due to honest mistakes or because they didn't learn what they were supposed to learn.
In my experience, studying mathematics is a bit weird. If you are ready to learn a topic, it's probably the field where you can get top grades with the least effort. But if you can't learn something with reasonable effort, hard work is unlikely to help. Doing something else and trying again after a few months might help.
If you are ready to learn a topic, it's probably the field where you can get top grades with the least effort.
Depends on your school. At my school, someone who was not super-talented in math but who works hard and is actually smart about studying is a 70s-80s student. The students who got 100s were basically IMO-level elite mathematics kids who were heavily recruited by the school and given full ride scholarships.
The course exams were essentially designed so that a "meets expectations" was a final grade of 65%. A grade of 100% is someone they were looking to recruit into research internships, grad school, and potentially a tenure-track position.
What skill are you grading? Can you expect some students to be able to churn out the problems? Are they doing design work? Is it more inventive or more creative? Is there more than one solution? How rigorous is the solution?
My point is that you can design an exam to test for speed and ability to do the day to day well. You prepare for this exam with lots of practice. There are a few problem types but you might not have seen every one. There's a basic level of extrapolation you're expecting.
You can design an exam for abstracting theory, and you prep for this exam by doing the hardest problems you can find, reading more theory, etc. You might not have seen anything like this but the test is to use the tools you're given in a class well. The test is the extrapolation.
I had theory courses where I expected the latter and practical courses where I expected the former.
There's more than one type of mastery; I bet your math professors would get destroyed by gifted 14 year olds in algebra competitions that involved arithmetic and timing. Do those 14 year olds not have more mastery?
>The novelty is gone, dealing with AI now feels frustrating and boring, I miss engaging deeply with the actual lower level technical challenges.
Honestly I've had the opposite experience.
If I can leave the boring crap to the LLMs, I can focus more on the deep important bits. The bits where the LLM accuracy is spotty because there's a ton of moving pieces and the "how/what" of the code becomes crucial for auditability and debuggability. The code that I've written bugs in, that Opus has written bugs in that code, where the design around it to make that less catastrophic when it happens is often system-specific and unique.
If I can spend 5 minutes delegating all the tedious plumbing updates around it, then I have more time to put towards the core.
The system design challenge becomes making sure that they are well separated.
Managing fleets of agents hasn't entered into the picture because the needle-moving things there tend to be successive and cumulative, not easily parallelizable. (I believe this is true on the product side as well - 10 crappy MVP features in a week would be way less interesting to me as a user than 1 new feature released in a 3x-more-fleshed-out-way than it would've been three years ago.)
> I think centralized code hosting is pretty much going to get killed by AI. Just like it's doing to social media.
Private corporate codebases are a poor fit for GH because they don't benefit from public social graph effects. And the typical codebase isn't so large as to be technically challenging to deal with with OSS tools. I'd guess they make up a substantial share of revenue.
But once the reliability is called into question, self-hosted or smaller alternatives start to look good. Although there's some trickiness there if you want to be super cautious about making sure you can get to your code+infra in case of a vendor incident, especially if you're cloud based.
> But I’ve also had a friend that was completely convinced that vinyl sounds the same as spotify, and that anyone who thought otherwise was just a pretentious poseur.
This is a great example because the ambiguity could go either way (e.g. spotify lossless FLAC vs vinyl will set off picky people on each side).
Sometimes different is just different, and each will be better to some.
Yeah, frankly I'd have more money and be happier when watching a lot of movies if I couldn't tell the difference between OLED black levels and projector/LCD ones.
I didn't ask for it and I don't want it, hah.
I feel no need to convince others that they should try to find the difference.
I'm happy that, say, cheap wine doesn't give me the same mental-twitch.
Yeah, a lot of "it doesn't matter how the code looks" convos seem to be ignoring that we know what happens over time when you just make tactical the-tests-still-pass changes over and over and over again. Slowly some of those tests get corrupted without noticing. And you never had the ENTIRE spec (and all the edge-case but user-relied-on-things) covered anyway. And then new dev gets way harder.
An LLM-generated TLA+ model can be verified for certain things in a way that LLM-generated code can't. It's infamously hard to exhaustively unit-test concurrency.
Whether or not you're modeling the right things or verifying the right things, of course... that's always left as an exercise for the user. ;)
(How to prove the implementation code is guaranteed to match the spec is a trick I haven't seen generalized yet, either, too.)
First counterexample that comes to mind: Rails vs 90s networked/shared line-of-business crud app development was a 10x factor. It also enabled a lot of internal tools that wouldn't have been worth doing without it.
But after people's expectations adjusted it was just back on the treadmill.
I don't think we've found a new steady-state yet, but I have some gut feeling guesses about where it's going to be.
90% of my my experience has always been dealing with large-ish corporate systems.
I am in Europe, so YMMV even when talking about corporate instead of smaller scale projects.
In my experience stuff like RAILS had negligible impact in my field because companies would always require solid backup from some big name vendor (MS, Oracle, IBM, Sun - back in the day, or even SAP).
So most if not all the smaller silver bullets did not even make a blimp on the radar... and stuff like Java or .NET, while definitely better than C or COBOL... did not really deliver in terms of productivity boost (in part because, as noted in the message I am answering to, expectations kept growing at the same pace)
>90% of my my experience has always been dealing with large-ish corporate systems. I am in Europe, so YMMV even when talking about corporate instead of smaller scale projects.
>In my experience stuff like RAILS had negligible impact in my field because companies would always require solid backup from some big name vendor (MS, Oracle, IBM, Sun - back in the day, or even SAP).
>So most if not all the smaller silver bullets did not even make a blimp on the radar... and stuff like Java or .NET, while definitely better than C or COBOL... did not really deliver in terms of productivity boost (in part because, as noted in the message I am answering to, expectations kept growing at the same pace)
I've always been in small-to-midsized US corporate where Oracle etc were generally "no way are we gonna spend that much" but if someone can hack a decent thing together and run it on a spare server... that got traction 10-20 years ago.
I'm curious if those large corporations are more homegrown-code-by-AI-friendly than they would've been towards homegrown-Rails-app? A lot of the same potential problems exist.
In particular if that steady-state requires 4 to 40GB blob of binary code to be installed or an internet connection to an AI SaaS provider and a credit card.
I remember when coding was free as in beer and freedom!
It's okay. In the near future people will not own a computer of significant capability at all, so it's not like they'd even be able to develop without a cloud connection in the first place.
And, for the most part, they will be okay with this. Gen Alpha or Beta will tell each other how morally wrong it is to expect for everyone to own a computer or even a smartphone, citing the environmental impacts, slaves mining coltan, and the toxic emotional effects upon people who grew up in the Social Media Dark Ages. Much like present-day Hackernews feels about personal automobile ownership.
Ah, Fails. "Before we made x improvement, the app had to restart 400x a day, now it's only 10x!"
For all the complaining we do about "enshittification", we (Hackernews, the broader industry, whatever), are perfectly willing to pay the price of stability and performance to get a little development speed. That's one prong of how enshittification happens. "I can make compromises in the quality of my product because time to market is the one thing, the only thing that matters in this move-fast-break-things economy—and pass my savings on to the customer (in the form of hidden costs)!"
I've never seen "lake" or adjacent terminology refer to S3 specifically like that vs other object storage. A data lake on Ceph would still be a data lake.
(My quibble would be that "lake" often refers to inconsistent or unstructured, and itself has always been a bit handwavy compared to "warehouse," whereas this is very structured data on object storage.)
reply