I built Lime Reader, a minimal site which displays time-sorted top posts from Hacker News, Tildes, Lobsters, Slashdot, Bear, and some science, tech & programming related subreddits.
You can read more about the site by clicking the slogan at the top of my site "your daily compass for the STEAMD web":
Previously, I have always used Rust or NodeJS for my backend and Postgres for database.
This time, I used Swift for my backend to build a Website for the first time, used SQLite for Database, used only a single third party dependency: Vapor for web server in the Swift app, and am self-hosting it all on an old Mac mini.
I really hate huge bloated sites and also hate adding third-party frameworks unless absolutely needed. Therefore, I have engineered Lime Reader to be as small in size as possible so that it loads instantly. Both PageSpeed Insights and Pingdom rate my site's performance as Excellent.
It's server side rendered, so it works even with JavaScript disabled (though enabling it gives you a few extra features like quick access to archive.org for each link). Kind of works even with CSS disabled.
The site doesn't have any ads (I hate them and have installed ad-blockers everywhere!), no trackers, or analytics. CloudFlare automatically enables Real User Monitoring (RUM) on sites. The very first thing I did was disable this thing.
I am self-hosting the site on an old Mac mini. It's a 2020 Intel model which has a 2018 chip (Intel's 3 GHz 6-core Core i5) and 32gb ram. Qwen model takes about 5.5GB of ram usage and does my headline classification in about 2 seconds each.
The Swift app talks to a locally running Qwen3 8b LLM for classifying whether a headline is political or not. This is done over a REST API by Ollama. This seems to work pretty well and far better than Apple's Foundation Models. Originally, I tried using Apple's Foundation Models for this classification. When it worked, it worked decently well. However, many headlines (and even pretty bland headlines) would somehow trigger its guardrails. I asked Stack Overflow for help on this but as usual, they closed the question for lack of details:
This does end up allowing some texts to work. However, it still failed for some other ones. That's when I gave up on using Apple's foundation models and switched to the Qwen3 8b model which had no such issues. It's pretty sad how the Foundation Models have so much potential but Apple has severely neutered them.
I originally tried the apple foundation models on my newer mac with m4 chip and once I had the issue with their guardrails, I decided to just switch to Qwen model which runs on Intel and used my old Mac mini for it.
An issue I ran into was that my Swift app was intermittently crashing. Root cause were two issues:
1. First one had to do with accessing the SQLite database from multiple threads. Apparently, for multi-threading use, SQLite needed to be initialized with a `SQLITE_OPEN_FULLMUTEX` flag.
2. Second one was a "Bad file descriptor" error from the macOS operating system itself. Had to do with a possible bug in Process.run() which would cause it to crash after some time:
busymom0•1h ago
You can read more about the site by clicking the slogan at the top of my site "your daily compass for the STEAMD web":
https://limereader.com/about
Previously, I have always used Rust or NodeJS for my backend and Postgres for database.
This time, I used Swift for my backend to build a Website for the first time, used SQLite for Database, used only a single third party dependency: Vapor for web server in the Swift app, and am self-hosting it all on an old Mac mini.
I really hate huge bloated sites and also hate adding third-party frameworks unless absolutely needed. Therefore, I have engineered Lime Reader to be as small in size as possible so that it loads instantly. Both PageSpeed Insights and Pingdom rate my site's performance as Excellent.
It's server side rendered, so it works even with JavaScript disabled (though enabling it gives you a few extra features like quick access to archive.org for each link). Kind of works even with CSS disabled.
The site doesn't have any ads (I hate them and have installed ad-blockers everywhere!), no trackers, or analytics. CloudFlare automatically enables Real User Monitoring (RUM) on sites. The very first thing I did was disable this thing.
I am self-hosting the site on an old Mac mini. It's a 2020 Intel model which has a 2018 chip (Intel's 3 GHz 6-core Core i5) and 32gb ram. Qwen model takes about 5.5GB of ram usage and does my headline classification in about 2 seconds each.
The Swift app talks to a locally running Qwen3 8b LLM for classifying whether a headline is political or not. This is done over a REST API by Ollama. This seems to work pretty well and far better than Apple's Foundation Models. Originally, I tried using Apple's Foundation Models for this classification. When it worked, it worked decently well. However, many headlines (and even pretty bland headlines) would somehow trigger its guardrails. I asked Stack Overflow for help on this but as usual, they closed the question for lack of details:
https://stackoverflow.com/questions/79785822/how-to-disable-...
For example, this headline:
> SEC approves Texas Stock Exchange, first new US integrated exchange in decades
Would hits the Apple's guardrails and throw an error saying `refusal: May contain sensitive content`.
Apple does provide a "permissive guardrail mode" as per:
https://developer.apple.com/documentation/foundationmodels/i...
This does end up allowing some texts to work. However, it still failed for some other ones. That's when I gave up on using Apple's foundation models and switched to the Qwen3 8b model which had no such issues. It's pretty sad how the Foundation Models have so much potential but Apple has severely neutered them.
I originally tried the apple foundation models on my newer mac with m4 chip and once I had the issue with their guardrails, I decided to just switch to Qwen model which runs on Intel and used my old Mac mini for it.
An issue I ran into was that my Swift app was intermittently crashing. Root cause were two issues:
1. First one had to do with accessing the SQLite database from multiple threads. Apparently, for multi-threading use, SQLite needed to be initialized with a `SQLITE_OPEN_FULLMUTEX` flag.
2. Second one was a "Bad file descriptor" error from the macOS operating system itself. Had to do with a possible bug in Process.run() which would cause it to crash after some time:
https://github.com/swiftlang/swift/issues/57827
Was able to fix it using the above workaround/solution of "fileHandleForReading.close()".
Lets see how long the site stays alive now without crashing :)
Feel free to ask questions.