SamWhited

Reminds me of the first company I worked for out of school.

We had a big drive with the source of truth image used to boot all our machines on it, and we added rsync to the init image. When each machine booted init would rsync everything from the storage box to the local machine. We'd keep the storage machine up to date and when we wanted to update other machines in the fleet we'd just do a reboot and it would sync up the latest files (provisioning for whatever each machine was supposed to do happened later, can't remember how that was handled now). The storage machine was running ZFS so we also took a snapshot before doing any rolling reboots, so if anything did go wrong you could just revert to the previous snapshot and reboot again as long as you didn't break the init image.

Sounds jank saying it out loud, but I don't remember it ever causing us any problems.

They actually have a (very new, still alpha, probably not a ton of data yet) database for books:

https://bookbrainz.org/about

I haven't looked into what their schema is like, but if it's anything like Musicbrainz it will be pretty comprehensive and easy to pull the data you want out of!

Doesn't help fix your problem, but I have a similar issue with Google Cloud Platform. Years ago I had a free workplace account that I had some small company emails and what not on, and apparently at some point over the years I setup a GCP project or two. Fast forward to the modern day and I haven't used the account in years so I decide to delete it. As the admin I hit the delete account button and it complains that I have services still active, so I go disable all the services which includes removing the workplace subsccription with all my billing info. I then hit delete again, at which point it complains that I have a project on GCP (not active, just created). So I go to delete it... which requires having a (paid) workspace account. So I can't delete the unused project without paying to re-activate the workspaces account I deleted, and I can't delete the whole account without deleting the GCP project. And of course Google has literally no support, so I just have a Google account hanging out there somewhere, probably with vaguely sensitive information from years ago on it, waiting for someone to guess the password or otherwise get into it.

Also if there's a tiny network blip before buffering is complete everything goes to hell. I don't get streaming DJing in general, seems like something serious DJ software should avoid (unless they're targeting the casual party crowd, which is fine)

Every user who uses a screen reader has been asking for this. Also, though I can't speak to this personally, apparently the theming engine is much easier to maintain in QML which is a big time saver for the devs.

FYI this is not a new major release, this is work starting on a new major release. At least two more versions of 2.x are planned and 3.0 is not yet actually scheduled.

May not have been what you meant, but I wanted to clarify for others reading this comment: 3.0 is quite a ways off.

FWIW I've found mixxx to be much more stable than serato or traktor (commercial stuff). I can't say whether they focus on bugs or features like your criticism suggests.

Organic Maps is a way to distribute OSM data, but it also has a lot more than just the OSM maps it uses (code to curate and collect those maps into downloadable packs, code to display them, code to do routing, design assets and resources for the app, documentation, etc.)

You're correct that the maps are OSM though, you can always contribute to OSM and that will also help Organic Maps (or whatever new community based map project comes out!)

Even if there's not a mapping Mixxx has a "MIDI Learning Wizard" (I forget what they call it) where, assuming it speaks MIDI, you can plug it up, choose an action, and then move the control for that action and it will figure out how to wire it up. For simple configurations that don't require scripting (ie. no setting LEDs on the controller or what not) you can get a fully functional setup for a controller Mixxx has no knowledge of without writing any JavaScript or XML at all!

Find definition of Foo():

  grep -IR "func Foo("

Show uses of Foo():

  grep -IR "Foo("

Hmm, what were the methods in that field again? Open a split pane in Vim and scroll down in the second pane to where the field is defined. Also I pretty much just have the standard libraries of my most commonly used programming languages more or less memorized and keep the docs open in a separate window alongside as well for when I don't. And of course in a sensible language that actually gives you feedback (I'm aware some languages are more or less strict about this and it's not an option for everyone): when I try to build it, it will fail, indicating that I've done something wrong. This is okay, use the build loop and embrace the build errors.

*EDIT:* updating to address "CoPilot" specifically, as I don't think it's the same as the other things on your list. I have reviewed a lot of submissions that were written with various AIs and all of them without fail, this is not hyperboly, all of them were just bad (I'm sure someone will say that if you just use it for a 1 line error tweak it will be fine and what could go wrong there? And sure, probably, but if that's the case you're not getting any benefit from them so that's not what I'm interested in). The code was worse than a human would have written it, there were subtle bugs that no one had noticed because they were trusting the AI, etc. just don't use them. They're not ready, they may be speeding you up, but they're slowing down whomever is reviewing your code. It's a serious disservice.

I had actually forgotten about this, I had a friend who had the exact same thing happen (dropped because "you have to use real names" or whatever, but they did use their real name, and it wasn't even anything suspicious or weird [not that that should matter], they just have a vaguely common for Eastern Europe sounding name :S)

That wasn't even the one I was thinking of; sounds like this has been happening a lot.

Indeed; no one ever seems to consider that before defaulting to them though :(

Good point, I wonder if you even can get a real person instead of an idiot stochastic parrot to review it anymore?

"hosting content going against their ToC or similar"

Or hosting content that Hetzner misclassified as against their ToC. Or that they decided was because of a string in a random file name. Or, in one Mastodon instances case recently, because Hetzner saw that users could upload their own images and decided that was risky (nevermind that this is common and they have moderation and a strategy for if someone tries to host anything illegal, but that one employee reviewing it was twitchy that day and there is no recourse), etc.

This happens literally all the time with Hetzner, I can't tell you how many times I've heard some variation of this story (or seen it here on HN), but they're cheap, and most people aren't going to find the people complaining online about it even if they do actually try to find out more about the company, so I'm afraid it hasn't hurt them much.

So any negative comment is somehow bias and I should be doing Matrix instead? I don't get what you're getting at.

I am still aware of both protocols, I still don't like Matrix and think XMPP is "good enough", or at least the best choice. Having an opinion doesn't make me biased against one or the other.

oh interesting, fair enough; I didn't know jabberd still existed! FWIW, Prosody, Ejabberd, OpenFire, etc. all mostly have sane defaults for a basic chat system (both in terms of performance and features). They won't be an exact match of course, but all the basic stuff should be there.

What servers don't have good defaults these days, and what clients need any configuration at all beyond the username and password? I don't think this is true.

Also Snikket meets your Docker requirements if you're into containers.

Partial graph sync is a thing, yes, but the graph still has to exist on both servers and expand as users request more of it, so the same analysis applies. But fair, maybe I should have pointed out that full sync is the worst case.

Or I did my research and made an informed decision which to work on. I didn't start working on one then only decide to dislike the other based on sunk cost fallacy. Matrix already existed when I got into doing XMPP stuff, and I looked into both.

All of those are newer XEPs for things that existed long before those XEPs or those specific versions if the XEP were published. There may be specific issues (I do remember that p2p file sharing never worked unless you were a network engineer who could tame nat), but I'm skeptical that they were still an issue when other protocols came along. I could be wrong, of course.

(oh yah, FWIW he's done this to me too; shows up and accuses me of being biased against matrix and not disclosing my affiliation with XMPP stuff… meanwhile he controls a company and gets paid by them, I just chose to work on XMPP open source stuff instead of Matrix stuff and don't get paid for it)

When was this? It's had most of these things for quite a while, but I'd be curious specifically what was missing and when or if there are still gaps?

To my knowledge it had most of these things before any other chat protocol was widespread and prior to the great silo-ing.

Slightly rambling partial agreement ahead, sorry, I struggle with how I feel about this and need to write something longer somewhere:

I think there's a tendency to dismiss this argument in the XMPP community (but there's a lot of truth to it, I choose to use the XMPP desktop clients but none of them are as nice to use as any big commercial IM providers client), but also a tendency for people to make this argument without realizing that they're comparing open source projects run by one or two people to VC funded projects with a company backing them. Of course Discord or Element or whatever will be "better" in some ways, they have a team and millions of VC funding behind them. However, one of the many reasons I chose to use XMPP back in the day when I was first evaluating whether to use it or Matrix, and one of the big reasons I got more heavily involved in the community later, was specifically because the standards body wasn't strictly tied to a company looking for VC funding (and all the individual client/server projects I've contributed to are the same). But, this does mean there aren't really any clients that I'm in love with (but there are clients for every random niche platform imaginable, which I think is probably more important personally).

All that being said, try Snikket if you haven't. It's relatively new, but I think they're really doing a good job of creating a suite of clients that can be recommended to "normies" who don't want to sacrifice shiny graphics for the sake of using something that's a bit more free from VC influence.

I don't know that it was ever "over complicated and hard to implement" (see my response to the thing you're quoting above, I think), at least, not any more so than any protocol, but I'm still not really sure what the specific complaints are when people mention this, maybe you could elaborate on what's hard to implement? Most people just grab an XMPP library and go, you don't normally have to implement XMPP itself to make a client (just like you don't implement HTTP when you want to make a request, you go snag a library that does this for you).

Matrix and XMPP operate in very different ways Matrix is a graph database synchronization protocol, whereas XMPP is event based.

Let's use group chats as an example: with Matrix if you join a group chat hosted on another server, the entire history of the chat gets synced to your server. This means it's very resource intensive to scale, but very reliable since you pretty much always have chat history available and if one server goes offline you can keep the group chat alive on one of the other servers (let's ignore netsplit style concerns for now, it's not really relevant to the high-level nature of the question). XMPP on the other hand is event based, this makes it much less resource intensive, but means that if the server you're trying to communicate goes down you don't have access to that chat room anymore (some servers mitigate this by using traditional high-availability techniques like clustering, but that's not really a protocol thing, I'm sure some Matrix servers also do clustering as part of their scaling strategy).

As far as features specifically related to IM, both support most of the same things, it's just a question of whether clients have implemented them or not in either protocol.

I've done a lot of work on XMPP related projects and some specs, and I'm not sure that this is true. I mean, it's definitely complicated, that part is true, but of course it is, it's a protocol and it's not more complicated than other specs as far as I can see. Not to mention that, like the various clients for different platforms that this article mentions, one of the big benefits of XMPP over other protocols is that it has libraries for every major platform, so most developers will never need to implement the spec.

TL;DR most people don't implement HTTP when they want to make a request, they add a dependency on whatever their languages HTTP library is. XMPP is the same.

This may be different per city, but at least near me this isn't true, the suburbs have a grocery (or several).

> Presumably if you pick one, you'll start to see the same faces, though

Sure, and you'll likely only see them in the grocery and not elsewhere. Probably the same with the bar; I too know a bunch of regulars at a local bar, but likely not going to run into them outside that bar unless we become friends and make specific plans to do so. Also those people probably aren't my actual neighbors. It's a different kind and frequency of chance meeting when the built-environment is designed to facilitate community. I'm not saying that you'll literally never meet a neighbor in the grocery, it will happen, it's just not going to happen with the same kind of frequency as if we actually designed the built-environment to encourage it.

It's much easier to get into town from a farm a few miles out than to the city from the suburbs. Plus in the city there are lots of places and in most of our cities they have similar walkability problems (I'm from Atlanta which is particularly egregious in terms of transit and walk/bikeability). There's not naturally that one place where your neighbors are going to go and happen to bump into each other. You have to first meet them, then plan "let's go to this bar at 13:00, and here's how parking is going to work, etc." as opposed to just "everyone is in town, or at the bar in their neighborhood, the obvious place where you're just going to happen to bump into someone else who showed up for happy hour" or whatever.

I'm sure I'm conveying the difference badly, but it's the difference between random encounters with your neighbors whom you'll see the next time you both go to the grocery and then walk over to the fun coffee place vs. random encounters with strangers you'll never see again.