45 comments

[ 0.17 ms ] story [ 67.7 ms ] thread
Oh wow. Off-topic but quite refreshing to see a site not absolutely plastered in AI posts
HN is increasingly bot central, I kind of assume 80% of the respondents are artificial.

Lobsters still got a pulse, largely.

It's a wonderful place. It feels like HN, but with the Silicon Valley attitude dialed way way way down, and with a much narrower scope (politics, economics and entrepreneurship are all off-topic, for example).
Lobste.rs is very anti-AI. They force any LLM topic to be tagged with “vibecoding” even when the majority of LLM posts are not about vibecoding.

AI posts are usually the most commented on. Linus Torvalds’ comments saying that LLMs are actually useful is still on the front page, tagged as vibecoding, and has a lot of comments from people mostly disagreeing with him.

Lobste.rs is more of a monoculture than Hacker News. If you get downvoted enough they stick a banner on the top of the page inviting you to delete your account. It has a nasty side effect of driving away good contributors who don’t align perfectly with the hive mind. It’s a site where you learn to keep your mouth shut if your input doesn’t agree with what the core users want to hear.

Wait, no edge cache, just one node with SQLite db?
Caddy does cache a portion of the traffic, and what it can't cache makes its way to rails.
For a relatively low-traffic site like Lobster's, yeah I'm not surprised they don't need anything crazy. SQLite is really efficient and modern hardware is really fast.
It's been fairly unstable recently, pages sometimes render for several seconds which I've never seen under MariaDB. Used to be instantaneous, always.

Sometimes (maybe 5% or less) the request won't render at all, and you get a browser error page.

Today they ran into this bug, lost a bunch of voting data, and went into read-only mode for several hours:

https://github.com/rails/rails/pull/57128

I wonder how much of this is usual bugs which crop up during major database migrations, and how much is caused by choice of SQLite.

No intention to antagonize but... why not postgre? Even my side projects run on postgresql with no overhead at all
Some of the cited reasons for moving off MariaDB [1] seem misguided, in my opinion. Especially the part about "K1 are very enterprise-focused, so the database is likely to focus its work on features that are not relevant to us. There's increased risk they drop the free/open source version we use"

K1 acquired the commercial entity behind MariaDB Enterprise, but that's separate from the non-profit MariaDB Foundation. And there's literally zero risk of the MariaDB server suddenly going closed-source; as a fork of MySQL (which is GPL), this is not even legally possible!

[1] https://github.com/lobsters/lobsters/issues/539#issuecomment...

The site is performing poorly for me. For example, the login page took 9 seconds to load, same with the home page.
May I have an invite, if anyone has one to spare?
I hope it's profitable, because this feels like engineering for engineering sake and not actually improving the product in a way that draws customers.
[flagged]
Another SQLite user here. My site gets constantly hammered by crawlers, and SQLite just keeps going on hit miss. Anyway, the real magic is on the ram and the ssd perf.
Does HN still use simple files for storing its data?
sqlite for a site that debates database migrations is like a chef who eats microwave dinners at home. makes perfect sense and somehow still feels like a betrayal.
I'd appreciate a lobste.rs invite if anyone has one. Email is in my profile. Thanks!
Some observations:

1. Stats are used by "Cost-Based Optimizers."

I think this is the most appropriate wiki:

https://en.wikipedia.org/wiki/Query_optimization

On my Oracle databases, I run the dbms_stats.gather_database_stats package procedure once a week. SQL Server also has stats for sure, and I would be surprised by a relational database that did not.

SQLite will quietly gather stats with each database connection. Running an explicit analyze devotes full attention to an otherwise piecemeal group effort.

2. I don't think rows are physically removed when deleted, instead they are marked. Removal will definitely happen at vacuum.

3. There is a backup command in the CLI that will make a transaction consistent copy of the database file, and there are lower-level C functions behind it that can be used with object code.

4. It is important to remember the many restrictions of WAL mode, including the impact on ATTACHing multiple database files: ACID consistency is lost.

https://sqlite.org/lang_attach.html

'Transactions involving multiple attached databases are atomic, assuming that the main database is not ":memory:" and the journal_mode is not WAL.'

Software “engineering”. Thank goodness bridges aren’t built with this level of rigor.

In any case I will take an invite if one has one because the community is solid.

Do you feel like lobste.rs is a better version of HackerNews?
Pretty cool. I do default to SQLite these days simply because I can just put it on the host, set up a PVC to it, and run the app in Kube pointing at a persistent SQLite. Absent some other need (it's a fork of psql- or mysql-based software) I prefer using it for simplicity.

I do have to say that I've found lobste.rs generally a pretty slow site to render and navigate and I wonder whether that's the Rails backend, or underpowered hardware, or lack of caching. It's more feature-ful than a HN or Reddit though with much lower usage so I wonder what it is.

Nice to see Lobsters is made with ruby

DHH has made a big deal about using SQLite in rails