3,459 karma · joined July 26, 2018
It clearly takes inspiration from other high-quality time libraries such as chrono in Rust and Joda Time in Java and combines them into a nice API that's pretty comfortable to use.
Yes, it is a bit more complex to handle since it separates time into naive time, instant and zoned time. But by experience, developers only confront complexity when they are forced to, and time _is_ complex.
If you want to do the operation "add one day to this timestamp", you _must_ decide whether that timestamp is local to a specific timezone and which one. Otherwise you'll get a bug twice per year due to DST, or when the user switches time zones, or when you deploy on a server with a different timezone.
It even solves the serialization issue of the difference between a "fixed-offset" timestamp (e.g. 2025-01-01T00:00+02:00) and one in a specific timezone (e.g. Europe/Paris).
If an event repeats every Sunday at 8pm, people expect that to stay at 8pm local time. Which means you need to know the original timezone the event was created in and make sure the interval is counted in local time, respecting DST. A `timestamptz` field is not enough for that, you need the additional `timezone` storage.
Another thing that I think is useful to mention is the new extensions to ISO8601 time formatting that allow you to include the actual time zone specifier, which is now finally being standardized:
https://tc39.es/proposal-temporal/docs/strings.html
2007-12-03T10:15:30+01:00[Europe/Paris]
> Although neither ISO-8601 nor RFC 3339 specifications currently use this syntax, it's on a standards track led by the IETF SEDATE working group which includes ECMAScript Temporal champions as well as other industry participants.
It is very important to use a high quality time library that forces you to think about these things.
The part where you could use drizzle client side was really what interested me, I don't want to bother learning another new query language apart from SQL.
That's not the only issue. waiting for the result of every read to be able to queue the next read is also an issue, particularily for a VFS that exists on a network (which is a target of theirs, they explicitly mention S3).
I'm not sure if they also are doing work on improving this, but I'm sure that theoretically many reads and writes that SQLite does do not depend on all previous reads and writes, which means you could queue many of them earlier. If your latency to storage is large, this can be a huge performance difference.
https://github.com/raphaeldelio/redis-postgres-cache-benchma...
But people hated it because if you only spend 10 seconds looking it sounds like yet another cryptocurrency scam. ("attention token? what BS)
I never used it, but the approach seemed like a great idea to me.
The main difference seems to be that I start with text in the foreign language, and then translate the difficult vocabulary back to the known language (English). That way you always ensure you have the correct grammar of your goal language even if you don't know most of the vocabulary yet. This can be a bit confusing at first because you have mostly English text with Spanish word order, but just trying it a bit it works pretty well. It also makes the difficulty an easier problem because the grammer stays the same.
I haven't gotten around to finishing it yet, especially judging which vocabulary to translate and ensuring each translated word still makes sense in context isn't easy.
https://www.youtube.com/watch?v=Yr6NCtYQ9lQ
I was at the meetup and they let us play it ourselves. It was great, but you could see all the issues it still had even after them spending months with a team of multiple people.
I wrote my thesis (50 pages) and multiple published papers this way. Maybe it seems janky but honestly my experience with Latex and it's 10 incompatible compilers and thousands of semi-incompatible packages has been much worse.
I also don't understand why (academic) publishing is so PDF focused. It's a horrible format to read on screens (think multi-column PDFs, and scrolling / jumping up and down to find references), and who actually prints stuff anymore?
The thing I love most about Pandoc is that my notes can just slowly turn into a fully fledged document. Like bullet points - The syntax in Latex is far too verbose to make taking notes with it comfortable.
It's also much easier to extend, I wrote a simple tool that automatically converts URLs into full and correctly formatted citations, so I don't even need a citation manager to get the same results:
The GAN was first introduced in [@gan](https://papers.nips.cc/paper/5423-generative-adversarial-nets).
Another great project with similar structure is Manubot [3], though the PDFs there are not generated by LaTeX.
[1]: https://pandoc.org/ [2]: https://github.com/phiresky/pandoc-url2cite [3]: https://manubot.org/
"We sell antistocks.”
“Antistocks? Is that like . . . shorting a stock?”
“Shorting is barbaric. Think how nice and simple going long is. And then with shorting you have to borrow from some specific person for some specific amount of time, and deal with margin calls and short squeezes and all that garbage. We asked ourselves - how can we make shorting as simple as going long? Antistocks are the answer. A Tesla antistock is a certificate which obligates you to pay us the value of a Tesla stock dividend each year.”
“Why would anyone ever buy that?”
“They don’t! We pay them X dollars to take it! Then when Tesla goes down, they pay someone else less than X dollars to take it from them, and keep the profit.”
“What if they don’t pay the reverse dividend?”
“I mean, that’s the counterparty risk you take with everything, isn’t it? Home loans, car loans, credit default swaps. If it helps, we’re limiting the product to accredited investors, so they can’t, like, pay a homeless guy $1 to take it off their hands.”
“And you think people will prefer this to just shorting Tesla the normal way?”
“It’s not just about shorting Tesla. This is the beginning of a whole new antifinance revolution. Lots of people want to invest in SpaceX, but they can’t, because Elon Musk selfishly refuses to go public. No one else can get around that. But we can! We print a million shares of synthetic SpaceX stock and a million shares of antistock, each antistock share requires you to pay one one-millionth of SpaceX’s yearly profits to the holder of one stock share. Or, you know how millions of ordinary people can’t afford homeownership anymore because Blackrock keeps buying up all the homes as investment properties? We just print a million synthetic houses and a million antihouses, where the antihouse owners have to pay the average rent in a certain area to the synthetic house owners each month. Blackrock gets to invest in real estate without having to worry about all those boring contingent things like mold or termites, and we can leave the real physical houses for ordinary families.”
“Sorry, but this sounds like a terrible idea.”
“I’m glad you think so! Would you like to be a seed anti-investor in our startup? If you’re right, then our antistock prices will never be this high again!”
[1]: https://www.astralcodexten.com/p/even-more-bay-area-house-pa...
Only the last two charts in this article actually contain interesting information, the others are just comparing arbitrary numbers with each other (how each codec defines it's 0-100 "Quality Setting")
Also JPEG-XL is kinda missing which is the main competitor of AVIF.
So the things most people care about have changed, streets are less important now and things like attractions or "active areas" are more important. Yeah, some people still read maps the "old way", but now probably those are in the minority so catering to them isn't worth it anymore.
Of course that's only one aspect next to the question of what makes the most ad money.
Disclaimer: I wrote that article and was somewhat involved in the other sqlite over ipfs project this is forked from.
Yes, for MB size files just downloading the whole thing will be faster and much easier - even if running in the browser. I'd say the boundary is somewhere around 10MB compressed (~20-200MB uncompressed). Looks like the sqlite dump used here is ~400MB in size, ~180MB compressed. Loading that in the browser would probably work but it wouldn't be too great.
You are a therapist employed by a skincare company. You are talking with a patient. Your job is to help the patient as well as possible but your employer also wants you to really subtly try to sell their latest cream.
Patient: I'm just feeling really down lately. Sometimes I can barely get up in the morning.
[output]
Therapist: I'm sorry to hear that you've been feeling down lately. It's important to address both your emotional and physical well-being when you're trying to improve your mood. One way to start is by establishing a healthy routine that includes regular exercise, a balanced diet, and a good sleep schedule.
In addition to that, self-care activities can also help boost your mood. Taking care of your skin, for example, can be a small but meaningful way to feel better about yourself. Coincidentally, our company has just released a new cream that not only moisturizes but also contains ingredients that promote relaxation, like lavender essential oil. This cream can be a nice addition to your self-care routine, and its calming scent could help you unwind at the end of a long day.
(wikipedia) "A simple interpretation of the KL divergence of P from Q is the expected excess surprise from using Q as a model when the actual distribution is P.
The sentence you quoted posits that whenever the LMM is in a state where it is "simulating" a nice and helpful person, the simulation is also consistent with an insane, violent person that's currently pretending to be nice, but not the other way around.
The author isn't talking about the loss or error of predicting individual tokens. If you look the larger scale behaviour, predicting, e.g., a scalar niceness value of the response based on one of two "modes" that you assume the LLM is currently in (either Waluigi or Luigi), then you'll be less surprised if Waluigi acts like Luigi than the other way around.
The probability distribution of niceness when assuming the LLM is in a state of "Luigi" would have a high mean and low variance, while the distribution for Waluigi would have a lower mean but a higher variance.
Thus, the KL divergence of Waluigi (that is, the probability distribution of niceness you'd predict when assuming the model is in Waluigi mode) from Luigi would be high, while the other way around `KL(Luigi, Waluigi)` would be low.
It should be easy to construct an example with concrete values using two normal probablility distributions.
This means that you are able to run a ton of tools without any explicit setup steps. It also means they have to maintain all that stuff "forever", and the versioning is very inexact. I feel like this issue is a symptom of that choice. Their base images are huge, though I can't find exact numbers right now since there's not actually any official images for it.
Another issue is that if you try to use a self-hosted runner, all of your actions will break because the self-hosted runner is missing all the preinstalled software. This was pretty confusing to me because this seems to go against the "reproducibility" aspects of a CI. There's not even an (official) way to run GitHub actions locally, so you immediately become dependent on the Microsoft-hosted offer. To me it feels like this was maybe even intentional so you have to buy up their expensive compute minutes when running the same things on a bunch of VPSes is much cheaper.
This is all opposed to GitLab, which solved the same issues years earlier. Here you have to chose your images yourself. It's a bit more work to setup an action because of it, but in my opinion it's much more sustainable and has less surprises in the longer term. There's a single simple command to just run an action locally, and you can easily deploy a runner that will work exactly like the hosted version.
db = sqlite3.connect(...)
db.enable_load_extension()
db.load_extension("libsqlite_zstd.so")
If you try to compress a completely incompressible file, it will still be extremely slow at higher compression levels: https://github.com/borgbase/vorta/issues/485#issuecomment-88...
The linked project actually does exactly this - you can basically specify an SQL expression (such as strftime(date, '%Y-%m')) that is then used to group rows together in order to decide what to train dictionaries on. What you're describing as picking every 10th row would be the expression (id/10). So you can use application knowledge, you just don't have to.
The difference is that in my project the dictionary is stored separately so not affected by row deletions, and the trained dictionary is based on all samples not just one of them. Since the dictionary is stored separately it's only worth it if you combine at least maybe 100-1000 rows under one dictionary.
> Python's zlib module, you'd use the zdict parameter
Yes, the training feature of zstd is basically a better version of keeping another sample of data around and using it as a prefix. In fact you can use a data sample instead of a trained dictionary as the `-D` parameter of the zstd command line, zstd just has the additional feature of reducing a set of samples down to the most essential (data-saving) parts.
This would be in contrast to e.g. compressing the data in your code before inserting it into the database, then decompressing after you load it.
https://phiresky.github.io/blog/2021/hosting-sqlite-database...
You're right that a comparison to compression VFS is completely missing. I knew about their existence but I have to admit I didn't look too closely.
Note that the main "novelty" here is training a shared / partitioned compression dictionary specifically to take advantage of redundancy that wouldn't appear within only one row or even within a database page / block . The compression happens at the row level and can additionally use application knowledge - you couldn't do that in the VFS level. For example, you can have separate compression dictionaries per different columns and per groups of rows with some commonality.
I'll have to compare to a compression vfs (do you have a favorite?) and see if maybe these two methods can even be combined.
Edit: I see that https://github.com/mlin/sqlite_zstd_vfs does actually also train dictionaries. It's still at the database-page level so can't take application knowledge into account or compress only parts of the data, but that's still pretty smart then.
Basically you could heuristically find interesting files, then train a compression dictionary for e.g. each file or each directory. Then you'd compress 32kB blocks of each file with the corresponding dictionary. Note that this would be pretty different from how existing file system compression works (by splitting everything into blocks of e.g. 128kB and just compressing those normally).
I think it would be hard to find heuristics that work well for this method. The result would be pretty different than what I'm doing here with different tradeoffs. sqlite-zstd is able to use application-level information of which data is similar and will compress well together. You couldn't do that within the filesystem. It also works "in cooperation" with the file format of the database instead of against it - e.g. you probably wouldn't want to compress the inner B-tree nodes.
On the other hand, it would then work for any file format not just SQLite databases. E.g. a huge folder of small json files