A posthumous sequel to 1984? Sounds a bit dystopian to me!

Then again I enjoyed Grendel, a retelling of Beowulf from a different point-of-view, so perhaps Julia could be enjoyed in the same way.

Agreed. My copy lost this documentation link in the original which gives more detail about the horizontal scaling: https://join-lemmy.org/docs/administration/horizontal_scaling.html.

It seems really straightforward (which is a good thing), each backend Lemmy_server handles incoming requests and also pulls from a shared queue of other federation work.

Time zones are an endless source of frustration, this one doesn’t sound too bad though:

Going forward, all timestamps in the API are switching from timestamps without time zone (2023-09-27T12:29:59.113132) to ISO8601 timestamps (e.g. 2023-10-29T15:10:51.557399+01:00 or Z suffix). In order to be compatible with both 0.18 and 0.19, parse the timestamp as ISO8601 and add a Z suffix if it fails (for older versions).

https://github.com/LemmyNet/lemmy/pull/3496

Thank This data structure uses a 2-dimensional array to store data, documented in this scala implementation: https://github.com/twitter/algebird/blob/develop/algebird-core/src/main/scala/com/twitter/algebird/CountMinSketch.scala. I’m still trying to understand it as well.

Similar to your idea, I had thought that by using k bloom filters, each with their own hash function and bit array, one could store an approximate count up to k for each key, which also might be wasteful or a naïve solution.

PDF link: http://www.eecs.harvard.edu/~michaelm/CS222/countmin.pdf

I haven’t used them in Spark directly but here’s how they are used for computing sparse joins in a similar data processing framework:

Let’s say you want to join some data “tables” A and B. When B has many more unique keys than are present in A, computing “A inner join B” would require lots of shuffling if B, including those extra keys.

Knowing this, you can add a step before the join to compute a bloom filter of the keys in A, then apply the filter to B. Now the join from A to B-filtered only considers relevant keys from B, hopefully now with much less total computation than the original join.

Collage sounds really interesting , will check it out. Another variation on bloom filter I recently learned about is count-min-sketch. It allows for storing/incrementing a count along with each key, and can answer “probably in set with count greater than _”, “definitely not in set”.

Thanks for adding more detail on the DB use-cases!

Pliers+Philips is a great combination. I was using a Trailblazer (Tinker Deluxe + Metal Saw/Chisel) and recently switched to a Mechanic (Tinker Deluxe - scissors/hook)

the science is spot-on

Good to know! This is a favorite of mine as well.

It gets recommended a lot, but Red Mars has a lot if science content, especially geology-related, in case you haven’t read it yet.

Thank you very much! Luckily, I have not yet read either of these — looking forward to them.

Although your current role wouldn’t seem very senior at a large organizational, “senior“ is a relative term and at this company it seems like you are the engineer with ownership responsibilities over the end-to-end software development of a production system. So it might still be reasonable to use a senior title if there are other benefits

This kind of debunking is much appreciated! And doesn’t detract from my enjoyment of the book (and it’s sequels).

You must have a high bar for science fiction as a scientist, do you have any recommendations tangential to this book? Thanks.

the author is more interested in how humanity as a whole would react to his fictional scenario than he is with writing characters with depth

This was my impression as well and I think it works only because the fictional scenarios are extremely creative along with sometimes gratuitous science-fiction details from the author’s imagination. And even though most characters seemed unrealistic as people I still liked them as characters and found them memorable.

I also read (listened to) Voyagers by Ben Bova recently and while the fictional scenario was interesting, the character development leaned heavily on the relationship between the hero scientist and the promiscuous young scientist, a writing style which I found more boring.

It’s probably not going to work as a defense against training LLMs (unless everyone does it?) but it also doesn’t have to — it’s an interesting thought experiment which can aid in understanding of this technology from an outside perspective.