Hacker Newsnew | past | comments | ask | show | jobs | submit | otoolep's commentslogin

I grew up in Ireland, moved to the USA as an adult. European government is clearly Hobbes in model, the US Lockean.

In Europe the individual has almost no legal reason to use force, and force by individuals is considered illegitimate. The "Sovereign" has all the coercive power in European states. In the US, however, a certain amount of legitimate force explicitly remains with the individual i.e. the 2nd amendment. (I am not making a value judgement here).

Of course, Europe has government with the consent of the governed, so is Lockean in that sense. But the balance of force between the "Sovereign" and the people in Europe is all Hobbes. You only notice it when you move to the US and compare it to Europe.

Europe had centuries of religious and civil war. It's not surprising Hobbes won out.


rqlite creator here, happy to answer any questions.

As for reliability - it's a fault-tolerant, highly available system. Reliability is the reason it exists. :-) If you're asking about quality and test coverage, you might like to check out these resources:

- https://rqlite.io/docs/design/

- https://rqlite.io/docs/design/#blog-posts

- https://philipotoole.com/how-is-rqlite-tested/


Blog post author here, thanks for your thoughtful comment. You raise some interesting things to think about.


>First of all, does anyone believe that highly scrutinized and bureaucratic functions are general high quality services?

This is the only part of your response that doesn't quite sit right with me. There could be many "highly scrutinized and bureaucratic functions" out there that are working very well, you just don't notice because they work so well. There could be a selection-effect here.

Quality is a big deal for me[1]. But I think you're defining "quality" too narrowly in this context. "Quality" could also mean "allows everyone, at scale, reliably, to do what they need to do." The US Tax Filing system (and its associated software) meets that goal.

[1] https://philipotoole.com/always-thinking-of-the-next-guy/


Oftentimes, broadly accessible services are lower quality than more personalized ones, to the consumer.

As an example in US government bureaucracy, government software teams digitizing forms at one point weren’t allowed to utilize features like autofill or automatically filling fields based on previous answers because it would relatively disadvantage users using paper forms.

Government capabilities do need to serve everyone, and from the perspective of the whole society that is beneficial, but they are often are of low quality to the individual consuming them for this very reason.

Let’s exclude taxes, because obviously many people would hate them under any circumstances. Does the government do a good job providing the other services people interact with regularly? Do people love their visits ti the DMV? Are they satisfied with their interactions with the police? Heck, in my town, just renewing a dog license is a pain.


> The US Tax Filing system (and its associated software) meets that goal.

I disagree with the argument that the US Tax Filing system meets the goal of:

> "allows everyone, at scale, reliably, to do what they need to do."

It may do so for easy / common cases of W2 salaried employees but step a little outside of the norm (foreign sourced income, tax treaties etc.) and software gives up and shows you a PDF of relevant forms and requires you to become an expert in tax code and to keep your own multi year running calculation of carryovers and things to proceed. I'm glossing over all of the detail about how complex this really is but wouldn't expect the average, even very intelligent person to succeed in filing a correct return without a professional's help.


my anecdata is that I have always filed manually by myself, but every time had a small adjustment made by the IRS... indeed filing a correct return the 1st time seems close to impossible.


rqlite creator here.

Yes I do have practical experience to share, I wrote a blog post on rqlite and FTS5: https://philipotoole.com/building-a-highly-available-search-...

Will it allow you to reach the same scale in terms of data set size that Elasticsearch supports? Almost certainly no, but it might be enough depending on your use case.


Hi, thanks, yes i have read it before this is why i am considering it. Will have to try.


rqlite[1] creator here, happy to answer any questions.

https://rqlite.io


Have you done any updated benchmarks on maximum supported writes/sec since the talk you gave comparing single-zone, single-region, etc.?

I recently had a potential use case for this, but it required somewhere around 600 writes/sec at a minimum, and it wasn’t clear what the ceiling was for rqlite without sacrificing durability guarantees.

Terrific bit of software, BTW!


rqlite creator here. I have performed a fair amount of performance testing, some of which I outlined in a talk to the CMU Database Group a few years ago. Details:

- https://www.philipotoole.com/2021-rqlite-cmu-tech-talk - see slide 33.

- There is also a recording that goes with the talk: https://www.youtube.com/watch?v=JLlIAWjvHxM

You can also read about Performance in the docs at: https://rqlite.io/docs/guides/performance/

An important thing to note: this testing was done 4+ years ago, on moderately-powerful hardware for the time. With higher-end, more modern hardware you may get even better results.


Thanks for the reply. Yeah, that’s the talk I was referring to.

I suppose I could try my own benchmark out tbf. I’m curious to see what it can do on today’s hardware. I would think it’s mostly network-bound for Raft consensus, though the 10x ping time increase you demonstrated without an appreciable drop in writes suggests it’s more complex than that.


Yes, fast networks matter.

I did introduce Queued Writes[1] since that talk, allowing you to trade off performance versus immediate durability. It may interest you -- network is much less of a factor then, and you should get a 10-100x increase in throughput.

[1] https://rqlite.io/docs/api/queued-writes/


Unfortunately for the application I was looking at using rqlite for, the possibility of data loss - however remote - was not an acceptable trade-off.


OK, well, you could try client-side batching too, if you can. That will also improve performance substantially.

Otherwise, if you try with more modern networks and disks, let me know what you see.


rqlite creator here, happy to answer any questions.


rqlite[1] creator here.

Nit: dqlite is a library, it is not a network-exposed database like rqlite is. Sure, it requires connecting to other nodes over the network, but local access is via in-process. In contrast one connects with rqlite over the network - HTTP specifically.

[1] https://rqlite.io


Massive fan rqlite. Awesome work!


rqlite[1] creator here. Thanks for the shout-out in your blog post.

https://rqlite.io


thanks for creating it! I'm really impressed by how easy was to use for dev and prod.


rqlite creator here. Right there on the rqlite homepage[1] are listed two production users: replicated.com[2] and textgroove.com are both using it.

[1] https://rqlite.io/

[2] https://www.replicated.com/blog/app-manager-with-rqlite


rqlite[1] author here. Just to be clear, rqlite is not SQLite but rewritten in Go. rqlite uses the vanilla C code, and calls it from Go[2]. I consider that an important advantage over other approaches -- rqlite gets all the benefits of rock-solid[3] SQLite. As result there are no questions about the quality of the database engine.

[1] https://rqlite.io

[2] https://rqlite.io/docs/design/

[3] https://www.sqlite.org/testing.html


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: