That's exactly what history should be about. Ordinary lives of ordinary people. But it's mostly which King fought with which emperor and slept with which socialite.
Readit NewsThere's an Ericsson GH388 phone I used in 90s!
IIRC it was my first mobile.
Never used Nokia though it had major market share those days.
kopirgan commented on I switched from VSCode to Zed tenthousandmeters.com/blo... · Posted by u/r4victor
I am not much of a programmer only fool around a bit for fun and occasional profit. I find Helix to be very good for coding. Compared to Neovim, I could get LSPs going for go, c without any effort. Only thing is I haven't figured out much of debugging which I guess is must have for a serious coder. My favorite is printf and is enough for me across go, awk, c , Excel VBA macros and JS!
kopirgan commented on Databases in 2025: A Year in Review cs.cmu.edu/~pavlo/blog/20... · Posted by u/viveknathani_
After 2 years in production with a small (but write heavy) web service... it's a mixed bag. It definitely does the job, but not having a DB server does have not only benefits, but also drawbacks. The biggest being (lack of) caching the file/DB in RAM. As a result I have to do my own read caching, which is fine in Rust using the mokka caching library, but it's still something you have to do yourself, which would otherwise come for free with Postgres.
This of course also makes it impossible to share the cache between instances, doing so would require employing redis/memcached at which point it would be better to use Postgres.
It has been OK so far, but definitely I will have to migrate to Postgres at one point, rather sooner than later.
I am no expert, but SQLite does have in memory store? At least for tables that need it..ofc sync of the writes to this store may need more work.
kopirgan commented on Databases in 2025: A Year in Review cs.cmu.edu/~pavlo/blog/20... · Posted by u/viveknathani_
Thats basically how the web started. You can serve a ridiculous number of users from a single physical machine. It isn't until you get into the hundreds-of-millions of users ballpark where you need to actually create architecture. The "cloud" lets you rent a small part of a physical machine, so it actually feels like you need more machines than you do. But a modern server? Easily 16-32+ cores, 128+gb of ram, and hundreds of tb of space. All for less than 2k per month (amortized). Yeah, you need an actual (small) team of people to manage that; but that will get you so far that it is utterly ridiculous.
Assuming you can accept 99% uptime (that's ~3 days a year being down), and if you were on a single cloud in 2025; that's basically last year.
I agree...there is scale and then there is scale. And then there is scale like Facebook.
We need not assume internet FB level scale for typical biz apps where one instance may support a few hundred users max. Or even few thousand. Over engineering under such assumptions is likely cost ineffective and may even increase surface area of risk. $0.02
kopirgan commented on Databases in 2025: A Year in Review cs.cmu.edu/~pavlo/blog/20... · Posted by u/viveknathani_
Why have multiple connections in the first place?
If your writes are fast, doing them serially does not cause anyone to wait.
How often does the typical user write to the DB? Often it is like once per day or so (for example on hacker news). Say the write takes 1/1000s. Then you can serve
1000 * 60 * 60 * 24 = 86 million users
That depends on the use case. HN is not a good example. I am referring to business applications where users submit data. Ofc in these cases we are looking at 00s not millions of users. The answer is good enough.
kopirgan commented on Databases in 2025: A Year in Review cs.cmu.edu/~pavlo/blog/20... · Posted by u/viveknathani_
From my perspective on databases, two trends continued in 2025:
1: Moving everything to SQLite
2: Using mostly JSON fields
Both started already a few years back and accelerated in 2025.
SQLite is just so nice and easy to deal with, with its no-daemon, one-file-per-db and one-type-per value approach.
And the JSON arrow functions make it a pleasure to work with flexible JSON data.
As a backend database that's not multi user, how many web connections that do writes can it realistically handle? Assuming writes are small say 100+ rows each?
Any mitigation strategy for larger use cases?
Thanks in advance!
kopirgan commented on The unbearable joy of sitting alone in a café candost.blog/the-unbearab... · Posted by u/mooreds
Japan is not the ideal place I would go to for a cafe, but I get the sentiment. When the weather is nice I love going for a morning walk with my dog on a lazy weekend morning and just sitting outside at a cafe reading a book. Coffee itself is secondary to this experience, it’s mostly just the vibe of the place that brings me there. That’s why small local cafes that don’t like people to sit at tables for too long are so off putting.
Never tried that in my Japan trips as life is too rushed. But have seen old Japanese cafe in Singapore where jap patrons sit for hours reading manga sipping coffee. I'm sure the culture is there in Japan too..
kopirgan commented on The unbearable joy of sitting alone in a café candost.blog/the-unbearab... · Posted by u/mooreds
Agree on the paper cup burning the tongue. Hate that too. But then coffee gets cold within minutes in porcelain cup.
Solution: I bring along a flask and use the paper cup as a cup and flask as cache. Means I lose the discount offered on byo but doesn't matter.
I notice most of the phones seem to be missing SIM cards = intentional disposal ? Or have they just come apart over time?
My early phones were all Ericsson later Alcatel which had a nice AA battery powered one! That was in 2000-01. First camera phone I think was a Siemens.
What a decline for European brands!