I used to wake up before school, dump my entire stack of gold on the GE for bones (just the regular ones) at a few gp below average price. By the end of the day the order would usually be fulfilled. Then I'd dump them back on the market at a few gp above average price and it would be fulfilled by the morning.
Most days it would net me a small profit, ocasionally prices would fall slightly throughout the day and I'd lose a little, but equally some days it would rise and I'd make extra.
If the market moves down after you bought, you are stuck holding the bag. You can either a) sell for a loss, or b) keep your item, and be unable to make further trades until the price (maybe?) recovers. Remember that OP put his entire stack into this, so he can't run the spread while his item isn't selling.
You can have unrealized losses since it's possible that the value of your items is less than the value of the goods you paid to receive them. To repeat this strategy the next day, you need to convert your items back into gold and realize the loss (or just introduce more gold via other means).
lots of video games charge a fee of in game currency for a transaction through an auction house or other system. It acts like a sink against inflation in the video game economy
RuneScape did not, and did have massive inflation, to the point that some players would have trouble keeping their wealth in gold coins due to hitting the signed integer limit.
I have been using agenix and it is very helpful. I am also looking into writing a system module that makes it easy to generate secrets on the fly.
A lot of secrets are just things like, backend and frontend of some service need to be configured with matching keys, but are both running on the same device. In that case you could have a systemd service which just generates a new random key if it doesn't already exist, and then ensure that the dependent services wait for that service to complete. That way you don't have to store anything in git for those at least.
With agenix, you can encrypt your secrets, such as API keys, and have them stored in your git repo alongside the system configuration (which in nixos is just a bunch of text files). Then you only need to provision the server with the ed25519 private key corresponding to the pubkey the files were encrypted with, and agenix will automatically decrypt the files on boot and place them in /run/agenix, with the specified access permissions.
So you still need a secret when provisioning, and you need to handle change management for that, and storing it securely outside of the git repo. And agenix did not change that workflow, or did it?
I only need to care about my SSH key(s). Which I had to anyway. But now the secrets for all the services (except SSH) lie right besides their config. Any change in one or other is directly visible in git log.
In short, age cut down on the number and types of secrets that I have to manage out of band. Which is very good. It's always easier to be able to remember 2 things (config + SSH keys) than 2+n things (config + SSH keys + whatever secret mechanism any service uses, times number of services).
So like SOPS, but specific to nix somehow? What is the advantage of the nixy integration here vs the universality of SOPS? Better native integration with NixOS?
To clarify maybe, NixOS puts all configuration and program files it handles in a world-readable object store on disk. If you want to manage secrets on NixOS securely, you have two choices:
- Manage it out of band. That negates all of the benefits of NixOS, at least for those files. (I.e. you would need additional deployment steps, rollback wouldn't work, you would have to stop and migrate system services that depend on those secrets yourself, etc.)
- Encrypt it and only decrypt it on activation (which happens when switching to a new config or on boot). agenix and nix-sops (the premier SOPS/NixOS integration) are two libraries that you can include in your config to do that. With this, the world-readable store only contains encrypted secrets.
Of course with #2 you still have to manage your private keys (age or whatever SOPS uses) out-of-band but that is significantly less work since those aren't expected to change nearly as much. You can also generally decouple that from your day-to-day deployment workflow.
What we are seeing here, and in many other cities across the world, reminds me of the Cantillon effect[1].
Basically, businesses which are in closer economic proximity are receiving the benefits of inflationary monetary policy sooner. This leads to higher wages for their employees, and higher profits for the B2B business partners, slowly spreading the new money out into the economy.
This seems to be leading to large gluts of artificially wealthy people in some areas, bidding up prices in their local economy, and then searching for areas to move into where the effect of the recently printed money hasn't taken hold yet.
The result of this would be a shift in those new economies to cater for the influx of new money coming from the newcomers, and away from dealing with locals who, for the most part, are yet to receive any of this money. And when they finally do begin to have wage increases, even more money has been created flowing at a greater rate to the newcomers.
Bitcoin has a locktime opcode[1] which allows you to set a time when the transaction output can be spent, effectively locking the funds irrevocably for a fixed amount of time.
Most days it would net me a small profit, ocasionally prices would fall slightly throughout the day and I'd lose a little, but equally some days it would rise and I'd make extra.