Congrats on the release! I enjoyed ArchiveBox while I used it, but had to stop using it because the bundled Chromium would get stuck almost daily, bringing my laptop to a crawl. It was a known bug, but it looks like it has been fixed! ( https://github.com/ArchiveBox/ArchiveBox/issues/1714 )
I'm looking forward to updating and trying out the new features as well :)
Yes, it was (still is) an annoying Chromium bug that affects tons of browser automation projects, not just ArchiveBox.
But v0.9.x now has built-in chrome zombie killing at the start of every crawl, so it shouldnt happen anymore even if Chromium misbehaves! Definitely open a github issue if you see any performance issues at all!
Pidgin 2.x (latest stable branch) is unfortunately over a decade behind at this point. The developers are working on a big rewrite (3.x) but it's nowhere near complete or ready for use yet.
In short, I wouldn't recommend Pidgin for someone who wants a modern messaging app.
Yes, XMPP server implementations typically give admins full control over data retention. Different use cases demand different settings, so it's quite adaptable to whatever needs you have.
I'm not sure what you mean by not handling encrypted messages fully, it handles encrypted messages fine.
> so it's quite adaptable to whatever needs you have.
as a user you cannot, even if you self host, because you are not the one controlling message storage
> I'm not sure what you mean by not handling encrypted messages fully, it handles encrypted messages fine.
you can load encrypted messages (including keys if they are needed to decrypt them if necessary) using a fresh login such that you can read them again?
FWIW I'm the founder of both the Snikket and Prosody projects. If you're a FreeBSD user, or even an experienced hands-on Linux sysadmin, I'd probably recommend going with Prosody, unless docker is your thing.
Snikket aimed to fill the gap for people who wanted an "out of the box" XMPP distribution kind of thing, and it's good at that. But shipping a bunch of software components with opinionated configurations doesn't really mesh well with distribution-level package management, and only really works with a container kind of ecosystem.
Both routes exist and are equally viable. Prosody has ports available for all the popular BSDs, and installing it should be a breeze. Just be prepared to then also set up a TURN server if you want calls, and potentially some web server stuff to if you want some of those features. After installing Prosody you can run 'prosodyctl check features' and it will tell you if you're missing any of the common stuff people want in a modern messaging app.
I can lend a hand, after spending a painful 10s on the website (which really needs some thought put into it if this is a serious project).
If you have any moderate experience with hardware hacking, you would be aware of a handy little hardware device called the Bus Pirate, which has been around in various forms for many years. It is designed to be like a Swiss army knife for connecting to devices and inspecting and debugging them. For example, it can decode/encode various common (and uncommon) digital protocols that are used by chips and hardware devices to communicate with each other.
This project... it appears that someone has (with a significant amount of AI-assistance, if the website is anything to go by) produced firmware for ESP32 devices which aims to replicate the functionality of a Bus Pirate. This is notable because ESP32 boards are much cheaper and widely available.
Without looking much into it though, my instinct tells me that it would be significantly more limited than the purpose-built Bus Pirate hardware.
You can do big data in SQLite. Concurrent writes, sure, I'd recommend something else.
If you think the majority of systems require massively concurrent writes, I think you need to look a bit harder. SQLite is, after all, the most widely deployed database system, ever.
We recently just partitioned the data into many SQLite databases and got away with it. It's telemetry data from IoT devices: one device, one database. Backups are an easy rsync job now instead of streaming a multi gigabyte database with compression that take hours. Reporting will just open each database and aggregate multi device data into another database (Duckdb, SQLite or something else, we'll see). Duckdb is not readable when locked so it's probably also going to be SQLite. Even it it's going to spit out JSON it will go into SQLite rows instead of many files.
I saw that but it's a bit too much friction. We'd rather attach a SQLite database and copy the results into that. Also no worries about version changes and compatibility, the types are not too restrictive. But we'll see.
Yes, which goes in line with the argument that claiming that it's "the most deployed" as proof of superiority or suitability for any use case is equivalent to claiming the same for Internet Explorer. It's the most deployed because it's bundled in a lot of systems, not because people are purposefully using it as a DBMS.
But it doesn't, because none of those systems are presenting SQLite to the user as something they should be using; they don't even make SQLite available to the user at all. Those systems all use SQLite internally to manage data.
It’s widely deployed as a local DB for local apps like phones, desktops, and web browsers. But it’s not the most used for distributed, concurrent web apps, which db servers were designed for. Maybe people are talking past each other, but that’s the debate I see.
It's a reference to Eternal September, the name applied to the cultural shift of the internet as the general public started gaining access to it en masse in the 90s.
Sloptember is clearly a reference to this - the similarity being that masses of AI generated content, from social media posts to open source contributions are replacing the human internet. In a way this is related to the "dead internet theory", an idea I previously found hard to believe, but these days could easily be true.
If the history of the internet interests you, both these are worth looking up.
A good way of thinking about it is that every commit is itself version-controlled, allowing unlimited edits. This even allows two people in an evolve-enabled repo to make changes to history at the same time, and Mercurial will resolve any conflicts. It makes it trivial to commit (and even share) a "WIP" commit which you can later amend/split/whatever. It's different from git where you basically can't edit history after pushing (in Mercurial this only becomes true if you push to a non-evolvution or "publishing" repo, where everything then gets squashed for public consumption).
To be clear, Mercurial does not have a staging area, but it does have allow selective commits (and selective uncommits) via prompt-based or interactive UI selection of hunks. Disagreeing with the need for a staging area is not the same as saying selective commits are unnecessary (I use Mercurial more than git and I rarely commit everything in my working directory in a single commit - I like small commits).
When there's an expectation or requirement that each commit builds (and even passes tests), how can you do partial commits? Do you work exclusively on projects without such requirements? Do you rely solely on CI to ensure that your commit compiles? Do you not use CI and not care if a commit is broken... you'll squash a fix in later, or not even squash it and leave a broken commit in the repo?
Each commit should build and pass tests, yes. When I say "partial commits", I don't mean that the commits are arbitrary - each commit should be as small as possible to implement a specific fix/feature. I've also heard it described as the smallest unit that you may want to revert.
For example, if you are working on something, but it requires adding an API to some module, then the first commit 1 is to add the new API (+ tests), and the second commit is the new code that uses that API.
Unfortunately many developers I have worked with would just combine these (and more) into a single commit (because they are part of the same work task). However this makes review, bisect, blame and revert harder (if you need to revert commit 2, you don't want to also revert the API you added if that was tested and bug-free).
Why would partial commits necessarily break anything?
In fact, often partial commits are necessary for builds.
As an example (and to be fair, this was a transitional project), I once worked on a project where the local dev directly acquired packages from different parts of the application, but the actual CI was broken up into different pipelines which required some parts to be built first, its outputs packaged and added to the registry, and downstream parts to be built after.
Committing everything at once would literally break the CI.
If the dev's working tree isn't exactly what they checked in, how do they build or test the commit? Do they YOLO a partial commit and wait for it to be accepted or rejected by the CI? Isn't that a problem to be solved by improving the CI pipeline?
I'm looking forward to updating and trying out the new features as well :)
reply