jobeirne

Or if you want to hedge against the various tail risks of third-party providers raising prices or denying you service or somehow abusing your data...

Someone rediscovered https://mcfunley.com/choose-boring-technology

Nope - in free societies you should be able to refuse service on any grounds, including those things. Otherwise you're permitting the government to forcibly compel you to allocate your time and resources to ends they define.

In free societies, governments should only be able to forcibly compel people not to do things (murder, threaten, steal, etc.) - see the concept of "negative rights."

In societies that have full respect for private property, I should be able to refuse to do business with you for any reason, including the color of your shoes, the kind of music you listen to, or your marital preferences. Whether it is wise or rationally self-interested to do so is a different question.

> But to expect that a _federal agency_ will be denied service from a private entity, especially for essentially political reasons, is lunacy.

Um, think you've got this backwards. Private entities shouldn't have to take on anyone they don't want as customers (for whatever reason - do you have to justify who you do or don't want in your livingroom?), but publicly-funded institutions shouldn't be able to deny service on political grounds.

It does parse docstrings in a very basic way (https://github.com/jamesob/clii#help-text-from-docstrings) but if you end up hacking in something you want, PRs are welcome.

Thanks!

Thanks. That's a really good point - maybe it's usable on earlier versions. Can't remember why I thought otherwise, will have to test.

Similar interface, different design goals. This lib has 6x the code, dependencies, and isn't as easy to vendor/audit.

I recently wrote this (https://github.com/jamesob/clii) because I can't stand click and got sick of having to check the argparse docs every time I wanted to write a CLI. I guarantee you'll spend a tenth of the time trying to figure out how to use this thing, it has no dependencies, and is implemented in a single vendor-friendly file.

I am so glad Bitcoin Cash exists for people like you.

You obviously didn't read the whole article because he explicitly covers refinancing during favorable rate changes - he has a whole section on 30yrs basically being implicit long vol trades on rates.

Website here: http://lightningresidency.com/

Chaincode Labs will be subsidizing flights to and lodging in NYC, so this is a great opportunity to get some experience building on top of Bitcoin using the Lightning Network.

Something from a few months back that's a bit closer to Bitcoin's actual implementation but at a similar level of readability: https://github.com/jamesob/tinychain

Stable according to whom? Check out all that stability in Venezeula.

It's called Bitcoin.

A block's timestamp is frozen in its hash, which is validated by any node receiving a block (whether during initial block download or otherwise). Bitcoin and tinychain don't accept blocks with a timestamp in the future beyond some threshold (in both cases 2 hours).

thanks :)

I link to some of my favorite resources at the end of this section: https://github.com/jamesob/tinychain#what-is-bitcoin

I also recommend subscribing to the bitcoin-core-dev mailing list.

Thanks! It's definitely meant for forking, hacking on, and experimentation. A few ideas:

- use dns for peer discovery

- implement Script language subset

- implement SegWit

See also: https://github.com/percolate/redset

Tempo Automation | Senior Software Engineer | San Francisco | ONSITE https://www.tempoautomation.com/

Join a growing team that's using software to revolutionize the world of electronics manufacturing. We are looking for some talented developers who want to make it as fast and seamless as possible for electrical engineers to manufacture their designs, iterate on their ideas, and bring their products to market. You'll be working on Python/Django full stack applications, robotic factory automation software, and CAD analysis tools.

Actually ended up wiping my phone because this coincided with a weird set of text attachments I got from someone who didn't knowingly send them. At that point I wasn't sure that my phone wasn't being keylogged, so I wiped to be on the safe side.

This project is reinventing a bunch of stuff that's completely orthogonal to the goal of a decentralized app platform. They've written an OS, a filesystem, a networking layer -- all in a completely new language that looks incomprehensible (https://github.com/urbit/arvo/blob/master/arvo/clay.hoon).

I doubt very much this project will get much traction due to the enormous conceptual overhead of working within its ecosystem. There's a huge learning curve approaching something like this from the Unix/C ecosystem, and I don't think it's merited.

Very cool project -- definitely recommend anyone interested in desk checks this out.

From what I can tell, though, desk's design allows for slightly different uses: namely (because desk consolidates configuration into one directory), desk configuration is more easily shareable across computers. In order to recreate your direnv setup on another machine, you'd have to go and symlink all your direnv files manually (unless they're somehow embedded in the repos or folders you're working in).

Direnv doesn't (AFAICT) attempt to surface documentation for the shell files it executes, whereas a lot of desk's value is in displaying a quick reference for common tasks within a workspace.