Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Lobste.rs is now running on SQLite

lobste.rs

Post reply on HN
Print view View original

111–120 of 209 posts

Re: Lobste.rs is now running on SQLite

#111

Post by zinodaur »

evanelias wrote: post #16

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. A…

As a big user of MySQL - moving off of it does seem like a good idea, if you can. The longer you wait, the harder it will be to flee

Re: Lobste.rs is now running on SQLite

#112

Post by veqq »

eterm wrote: post #43
homebrewer wrote: post #6

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…

SQLite definitely seems like a poor choice for dealing with many concurrent requests. Maybe it's improved since I last used it, but to my knowledge SQLite essentially forces all writes to be serialised, at risk of data corruption otherwise. There are tricks for improving the performance such as WALs, but that is merely a performance boost rather than genuine concurrency with things like row-level locks that you might…

edit: misread requests as writes

Re: Lobste.rs is now running on SQLite

#113

Post by eterm »

veqq wrote: post #112
eterm wrote: post #43

Earlier quoted context omitted.

SQLite definitely seems like a poor choice for dealing with many concurrent requests. Maybe it's improved since I last used it, but to my knowledge SQLite essentially forces all writes to be serialised, at risk of data corruption otherwise. There are tricks for improving the performance such as WALs, but that is merely a performance boost rather than genuine concurrency with things like row-level locks that you might…

edit: misread requests as writes

I wouldn't expect that problem to be solved at the database layer, that's what http caches are for, then application level in-memory caches, then finally if neither of those hit, go to the database.

For example, one of the biggest optimisations that Hacker news does is that it serves logged out users from a cached copy of the front-page.

Logged out users don't care/notice about comment counts, they don't notice that it doesn't update as often, they can't be hiding articles so you can serve the same front-page to the millions of anonymous users and bots, and update that cached copy once and on a slower cadence than every request.

Re: Lobste.rs is now running on SQLite

#114

Post by BoingBoomTschak »

Aurornis wrote: post #25
tetris11 wrote: post #2

Oh wow. Off-topic but quite refreshing to see a site not absolutely plastered in AI posts

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

Being anti-AI is fine by me, but the hardcore Tumblr dogma can be very tiring sometimes; even if only as a reader interested in the valuable technical comments.

Re: Lobste.rs is now running on SQLite

#115

Post by ai_critic »

gspr wrote: post #10
tetris11 wrote: post #2

Oh wow. Off-topic but quite refreshing to see a site not absolutely plastered in AI posts

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

Slight clarification: politics that disagree with the zeitgeist of the site and the mods is off-topic.

Re: Lobste.rs is now running on SQLite

#116

Post by [deleted] »

eterm wrote: post #113
veqq wrote: post #112

Earlier quoted context omitted.

edit: misread requests as writes

I wouldn't expect that problem to be solved at the database layer, that's what http caches are for, then application level in-memory caches, then finally if neither of those hit, go to the database. For example, one of the biggest optimisations that Hacker news does is that it serves logged out users from a cached copy of the front-page. Logged out users don't care/notice about comment counts, they don't notice that…

[deleted]

Re: Lobste.rs is now running on SQLite

#117

Post by mixmastamyk »

uproarchat wrote: post #106
Imustaskforhelp wrote: post #91

Earlier quoted context omitted.

I have signed up, thanks! You are awesome mate!, have a good day :-D

Take it easy :)

Please don’t post other’s addresses, after a bit are unable to be removed. If they decide to later it’s too late.

Re: Lobste.rs is now running on SQLite

#118

Post by wild_egg »

eterm wrote: post #43
homebrewer wrote: post #6

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…

SQLite definitely seems like a poor choice for dealing with many concurrent requests. Maybe it's improved since I last used it, but to my knowledge SQLite essentially forces all writes to be serialised, at risk of data corruption otherwise. There are tricks for improving the performance such as WALs, but that is merely a performance boost rather than genuine concurrency with things like row-level locks that you might…

> SQLite definitely seems like a poor choice for dealing with many concurrent requests

Can you qualify "many"? SQLite easily handles 100k+ writes per second and it's not hard to have app layer code serialize and batch writes to take advantage of that speed. Concurrent writes require a ton of overhead and your system and code can be quite a lot faster and simpler if you just skip the idea of them altogether.

Re: Lobste.rs is now running on SQLite

#119

Post by abetusk »

devilsdata wrote: post #65
tverbeure wrote: post #57

Earlier quoted context omitted.

I wish lobste.rs would be a tiny bit easier to get access to. Some of my blog posts have been discussed there and every time I try to get access, I can’t get past their IRC stuff. As in: I just don’t understand how IRC works…

I've been waiting for my lobste.rs invite for years. I joined the IRC for a few days, but being in Australia, rarely saw too much activity. I could chase someone down for an invite, but at that point I just don't care that much.

I was given my invite from a decent person who, I believe, basically has an "open door" policy. I'm happy to pay it forward and give you an invite if you want it. abetusk@mechaelephant.com
Post reply on HN