out of curiosity, who is this judge talking to again? A storage node?

wow... that spoiler was actually a spoiler. I was thinking "I should read that" till I hit that last line.

You should still read it. It's a very rare gem in the sci-fi literature.

It's amazing in any way you can imagine. In something like 40 pages you get presented with problems from several very different domains -- and proposed solutions.

Sorry about that, I removed the spoiler to not ruin the story for anyone else.

isn't it 10%? Main site says 10%, but I hear people complaining about 20%. I'm not sure what's going on here.

I don't know what website you are reading, but the Zcash website says it is 20% now but after 4 years drops to nothing, and when you account for the dropping rewards given to minors, after ten years (when mining will end) the result will be 10% went to the founders: so people saying "a 20% tax" are correct today even if the tax rate will amortize a long time from now to only be 10%.

> At first, 50 ZEC will be created every ten minutes. 80% of the newly created ZEC will go to the miners, and 20% ZEC to the founders.

https://z.cash/blog/funding.html

> Every four years, the rate of ZEC being created will halve (again, just like in Bitcoin). After the first four years the ZEC created per ten minutes will drop to 25ⓩ, but after the first four years, 100% of it goes to the miners.

> The end result (as shown in the diagram) is that there will ultimately be 21 million ⓩ, and 10% of it, or 2.1 million ⓩ, will have been initially distributed to the founders.

It's 10% of all ZEC over planned mining-distribution, but front-loaded: 20% of mining-rewards for the 1st four years, then 0% thereafter.

This is such a clean concept.

If you have a tiny application, doing a tiny thing, do you need redis? Do you need sqlite? do you need to write some custom-text-file-ma-bob? nah. I feel like simple simple little tools like this are in short supply.

OP here.

Use redis if you can. Use something like diskhash if you cannot afford the extra overhead of sqlite/redis.

In my case, the alternative we were using before is an in-memory hash table built at startup from a text-based representation of the data. It was pretty good and worked very well up to millions of entries, but at the current scale we work with, it takes least 10 minutes at startup were necessary to build up the thing and it used ~200GB.

They aren't in short supply, just about every shop I've worked at some tool decided to invent something like this instead of just using redis / sqlite.

Yeah but insofar as the article's author's revelation of how fast you can compile C code, maybe the correct answer is to use gperf?

If it's more dynamic than that I mean I guess it's cool to have a hash in a backing store that's dead simple.

But at sizes big enough and with enough dynamism that gperf or something similar isn't appropriate I think you should be considering dbm or SQLite, sort of by definition.

While I kinda agree, I also have found, most of the time, that by the time I finish building something that I thought didn't need a bigger thing...it actually needs a bigger thing, and I have to pull in SQLite or something else to make it all work reliably and fast and for all the data-related features that ended up being needed by the end.

That sounds silly, but that's when they killed the audio reader functionality so as to not compete with the audiobook industry right?

also it seems its not the paint that's expensive, but the retooling, so it's a one time cost.

really seems much ado about nothing.

Amongst other points, the article says that a water based paint takes 5 times longer to dry than the oil. From a production stand point you have a bottleneck. You now need 5x capacity to dry the containers to stay even with the normal production. Since I doubt they have vertical drying racks, production should slow due to that alone.

It's a classical 'flow shop' scheduling problem.

Either you increase the number of 'machines' (lines in this case) or you increase your drying area foot print to compensate.

Once you do the latter you can produce at the same rate assuming all products produced are identical) since you the ones coming out the dry end do so at the same speed as the input end.

Edit: This does assume production demand is constant, longer pipelines make responding to demand more difficult.

I am pretty certain paintings used for containers have little to none in common with paintings you get at the home improvement store but some observations I have made concerning water vs. oil based paintings:

* Water based paintings dry much faster than oil based paintings

* The durability is pretty much the same

* The scratch resistance of oil based paintings, once fully dried, is light years better than that of water based paintings.

In some aspects the green movement has brought us water based colors where you could water your home plants with but are inadequate for some (read: wide) range of application.

Oil based paint gets brittle and chips and it also yellows. A downside I have noticed in water based paint is the manufacturers have started adding extra water, thinning the paint. Presumably selling more water is more profitable.

You don't need 5x capacity. This is latency vs bandwidth - you're going to delay the orders during the process switch 4x the drying period, but after that, your normal throughout I back up.

Just thought I would mention: PassFF does not works with the current version of firefox. The current plugin does not work and is not supported. According to the author, we should wait for the Web-Extensions version which will be coming... no idea... soon? I asked about 2 months ago. So pass is basically just a command line password manager unless you run firefox developer edition.

You can use browserpass [1] instead, it's a web extension for Firefox and Chrome.

[1] https://github.com/dannyvankooten/browserpass

I just used PassFF this weekend on a fully patched Ubuntu LTS. It worked perfectly.

no doubt. if you politically object to anything on that list, you merely need to compare it to something higher up and force people into a binary choice. "Which would be better"?

a co-worker did this, it took him to a screen that was designed to imitate the windows blue screen of death.

I assume it was also attempting to deliver some kind of payload as well, because the browser crashed on that page.

There is no way an advertising standard in which google was a part of laying the ground rules could be considered a "Better Ad".

a dynamic site can't work without mutability, ipfs can't deal with mutability, so ipfs comes with ipns, which allows you to statically reference content that might change.

Yeah, IPFS + IPNS is effectively on par with Dat archive mutability, but mutability being built-in to Dat + its verifiable history log is particularly well-suited to building peer-to-peer websites

Of course, the design of IPNS makes it impossible to prove that you've got the latest version of a name's value, and makes it relatively easy to attack. I don't know if Dat has the same issue, I haven't looked at it.

It's not impossible by design, it's simply a feature that hasn't been implemented so far. IPFS is by design pluggable on all layers and thus theoretically capable of a ton of stuff.

So IPFS is, according to you, not defined as its protocol, but instead as its API? So I could build an IPFS implementation that just grabs stuff from my (centralised) web server and say I'm using IPFS? Either nonsense, or useless - the goal here, I thought, was to build a global decentralised filesystem that looks the same from everyone's perspective.

All DHTs suffer from this issue. It's just particularly likely that IPNS's use of a DHT will lead to attacks. Making it not susceptible to this would require a redesign of IPNS's protocol.