mcdee

It's called ineffassign

They use 1FL/1FR for first floor, 2FL/2FR for second floor, etc.

Why would carbon dating be relevant for extra-terrestrials? Without knowing the amount of C14 in their native environment, I don't see that you have a basis on which to calculate age from the current amount of C14.

With staking, the biggest holders just sit there and collect coins with few operational costs.

Every holder who is staking is rewarded for staking, in proportion to their stake.

To me it sounds like staking has a much more powerful snowball effect than mining

No, because issuance under proof of stake is much lower than that under proof of work.

The point of validating is to secure the chain, not to get rich. The more validators that are active, the lower the per-validator rewards, reducing compounding effects.

The "kiln" testnet is currently running and will carry out the merge in the next few days, which is the final step before the existing proof of work testnets transitioned to proof of stake and then the Ethereum mainnet itself. I think that counts as "obvious evidence".

In this case the third party could be the employer that pays the salary, or the bank that receives it.

The decision to trust the issuer or not is down to the entity viewing the information, and depends on the particular requirements of the situation. A zero-knowledge proof that I am over 25 issued by my local library may be enough for the local theatre to let me in to watch a suitably rated movie, but not for the local bar to let me purchase liquor (in the latter case a proof directly from a government entity would be more appropriate).

A slight aside, but so many of these keys seem to have the touch point / button applying force perpendicular to the direction of insertion, I wonder if there is any long-term potential to cause damage to the USB interface.

The point of having separate imports for separate versions is to allow for use of (for example) both v1 and v2 of a module within the same codebase, if required. Your idea would force a single version, which means that would no longer be possible.

It's non-obvious, though. Change something in /etc/systemd you can expect to have to tell systemd about it. Outside of that directory, there's no indicator you should do so.

"Long time" is also relative. I've been updating /etc/fstab directly for over 25 years.

All we store is an encrypted version of the user's master keychain

Is the seed created and encrypted on the client or the server?

Yet having moved from (primarily) Java to (primarily) Go I find I don't miss them.

The thief would transfer it to an address of their choosing, which wouldn't have a guessable private key (and obviously be known by the thief).

Additionally, we identified 13,319 Ethereum that was transferred to either invalid destination addresses

There is no such thing as an invalid Ethereum address.

Separately, what the researchers seem to miss is that the majority of these funds were stolen due to a far more traditional software exploit: the Go Ethereum client (geth) has a JSON-RPC interface. If the user:

  - enables the interface (it's disabled by default)
  - listening on a public address (it defaults to 127.0.0.1)
  - and unlocks their wallet (they are locked by default)

If anyone cares enough, it's easy to set up an instance of geth with the first two conditions met and watch the transfer attempts coming in.

Among other things, it includes a cost-based optimizer that can complete the TPC-H benchmark, CDC, and two major enterprise security features. But was this enough of a value jump to merit the leap to 3.0? Or was this a 2.2? Strictly following the semantic versioning rules would specify 2.2, as there are no backwards incompatible API changes. But with that logic guiding the major version bump, we could potentially remain on 2.x forever.

The whole point of semver is that it allows people to know if they can upgrade version without hitting incompatibilities. So yes, this would be a 2.2 and those on 2.1 would know that they could upgrade to it without worrying about fixing their own integrations.

The calender version 19.1 tells me nothing other than when it was released, which is of no interest whatsoever when evaluating what it does. Sounds like a triumph of marketing over useful information.

There are two separate issues. The lack of statistics is one thing, but the use of ->> instead of @> is another. Look at https://explain.depesz.com/s/zJiT Vs https://explain.depesz.com/s/ihwk for the difference.

True it doesn't solve the problem of not having statistics on the values, but it does bring the query response time down to the same order of magnitude as the non-JSON table.

I'm using JSONB and the downsides on performance are not noticeable for most cases. For those where there are real problems then crafting a custom index usually fixes the issue.

Using ->> (or ->) in a WHERE statement is generally a bad idea, and certainly a terrible idea without an explicit index. Use @> instead.

Actually the ISO format does not give you timezone information. It gives you offset from UTC, from which you cannot infer anything about the timezone in which the date resides.

Sysadmins generally have the highest levels of privilege on any given system. I've worked in and around sysadmins in some very large firms and when you're responsible for things like server installation, maintenance, and backups, it's very rare that you don't have access to all of the information on them.

Interesting. Would be great to have something like that with interaction built out as a simple component. Hmm...

So how much of this is open source and available? I can see lots of uses for something that looks this good and to which you can overlay your own information.

Sorry, just to confirm: GitHub's cost model aligns with your revenue model (as opposed to your cost model), and this is a bad thing?