zackelan
As a software engineer who builds their own desktops (and has for the last 10 years) but mostly works with AWS instances at $dayjob, are there any resources you'd recommend for learning about what's available in the land of that higher-end rackmount equipment? Short of going full homelab, tripling my power bill, and heating my apartment up to 30C, I mean...
I like that better than bringing racks into it, because once you have multiple machines in a rack you've got distributed systems problems, and there's a significant overlap between "big data" and the problems that a distributed system introduces.
It cuts down on the per-instance memory overhead, for cases where you're creating a ton of these objects. It can be useful even when not memory-constrained, because it will throw AttributeError, rather than succeeding silently, if you make a typo when assigning to an object attribute.
0: https://www.python.org/dev/peps/pep-0557/#support-for-automa...
This means that the "frontend" of a service can be asyncio, allowing it to support features like WebSockets that are non-trivial to support without aiohttp or a similiar asyncio-native HTTP server [2], while the "backend" of the service can be multi-threaded or multi-process for CPU-bound work.
0: https://docs.python.org/3/library/asyncio-eventloop.html#exe...
1: https://docs.python.org/3/library/asyncio-eventloop.html#asy...
2: Flask-SocketIO, for example, requires that you use eventlet or gevent, which are the "legacy" ways of doing asynchronous IO: https://flask-socketio.readthedocs.io/en/latest/
Similar use case - self-hosted VMs, for low-traffic, internal tools, and no need for autoscaling.
I can't speak to how well it integrates with Gitlab's Auto DevOps, but Nomad integrates very well with Terraform[1] and I'd be surprised if there wasn't a way to plug Terraform into Gitlab's process.
Under classic RDS, when your application makes a SQL connection (the data plane) it's talking to a more or less stock Postgres instance, the same as you would have if you ran it locally.
Aurora, on the other hand, is involved in both the control plane and data plane. Your SQL connection is to a Postgres instance that's been forked/modified to work within Aurora.
Here's what I think is the central (and flawed) assumption in this line of reasoning - people move to an area because of its "character". And that "character" is an intangible, immeasurable quality, but it is somehow diminished if more people move to the area.
I grew up in Seattle. Both of my grandparents, when I was a kid, lived in Seattle's Fremont neighborhood. I live in Fremont today. From one perspective, the Fremont of my childhood is completely changed. On the other hand, it's still Fremont, with the Center of the Universe sign and the statue of Lenin and many other things I remember from childhood. Does it have the same "character"? Does it have a newer, different, but just as good, "character"?
Those are impossible questions and it boils down to a Ship of Theseus style argument. Either way, I can't bring myself to assert that the housing supply of Fremont should be artificially constrained by zoning policies, in order to preserve my ideal of what Fremont "should be" or "used to be".
What I ended up with was (for a shortcut for generating a password on the command line):
function pw --argument length
test -z $length; and set length 16
python3.6 -c "import secrets; print(secrets.token_urlsafe($length))"
endThe "that's an intermittent failure, just re-run it and it usually passes" attitude is in my experience more likely due to just plain old poorly-written tests, usually with a time.sleep() or something similar that makes them unreliable.
https://redis.io/commands/slaveof
> A note about slavery: it's unfortunate that originally the master-slave terminology was picked for databases. When Redis was designed the existing terminology was used without much analysis of alternatives, however a SLAVEOF NO ONE command was added as a freedom message. Instead of changing the terminology, which would require breaking backward compatibility in the API and INFO output, we want to use this page to remind you that slavery is both a crime against humanity today and something that has been perpetuated throughout all human history.
For a more practical summary, compare the architecture overviews of Cassandra[2] and Cockroach[3].
0: http://www.allthingsdistributed.com/files/amazon-dynamo-sosp...
1: https://static.googleusercontent.com/media/research.google.c...
2: https://docs.datastax.com/en/cassandra/3.0/cassandra/archite...
3: https://www.cockroachlabs.com/docs/stable/architecture/overv...
Now with auto-naming, you create a service[1], then a service instance calls RegisterInstance[2] on start-up with a much simpler JSON payload.
0: https://docs.aws.amazon.com/Route53/latest/APIReference/API_...
1: https://docs.aws.amazon.com/Route53/latest/APIReference/API_...
2: https://docs.aws.amazon.com/Route53/latest/APIReference/API_...
By separating the router and wireless APs you also get the ability to place multiple APs throughout your home for improved signal.
"We are investigating reports of elevated error rates."
Anecdotally, it seems to work if not logged in.
It also serves the purpose of being something I can explain to less-technical relatives at the Thanksgiving table, and they immediately grasp the importance. If I started talking about Title II and common carriers and peering agreements it would have nowhere near the same impact.
> So: don’t treat this as a fully general Redis/MySQL benchmark. It really, really isn’t.
> I’ll repeat this one more time, so drive-by commenters look silly: this is a benchmark of our specific use case and no other.
To me it reads like barely-disguised native advertising, with every single chart having both the company's logo embedded in it and a direct link to their homepage right below it.
It's sad to see such content appear so prominently on HN.
This is true, and explicitly acknowledged by the author:
> SQLite does not compete with client/server databases. SQLite competes with fopen().
https://sqlite.org/whentouse.html
If you're deciding between Postgres and SQLite, in most cases you're doing it wrong (there are a few exceptions, such as serving a low-traffic almost-entirely-read dynamic website can be accomplished easily with either). Usually you want to choose between SQLite and "anything else that involves writing directly to the local filesystem".
Of course, SQLite can also emulate a key-value store quite well, with a table with 'key' and 'value' columns.
Insult to injury, if you're using Docker in a VM (as you must on a Mac) the instructions on that Docker Hub page say you need a minimum of 3.25GB RAM dedicated to the VM. That's quite a heavy lift if all you want is a database instance for local development.
And then sure, you could run SQL Server on Linux for your production instances, but you're well off the beaten path. You're going to have to roll your own infrastructure rather than relying on AWS RDS, Google Cloud SQL, Heroku, etc etc. And the moment you have a performance problem the first advice you'll hear seems likely to be "try it on Windows and see if it reproduces there".
Syncthing mirrors everything between my desktop, laptop, and phone (and there's an Android app[2] that works with OpenKeychain[3] so passwords are accessible from my phone). I haven't done this yet, but it'd be trivial to also run syncthing on a cheap VM somewhere, and replicate the passwords to it (but obviously not my GPG private key) for disaster recovery.
0: https://www.passwordstore.org/
Changing a single CPU-related flag in the BIOS should under no circumstances render a filesystem unmountable.
I think what that may be referring to is that the ARC is in-RAM and obviously cleared on a reboot, so as a result L2ARC on an SSD is also not persistent. After a reboot, you have to allow the ARC to fill up, then as it evicts data from the L1ARC it's pushed to L2ARC. Until that happens the SSD is not used at all.