wraithm112

Everything I've seen about OpsWorks is chef/puppet based. Ansible is not mentioned in the opsworks documentation at all. I think that's just wrong.

That and people have completely switched to MDMs to provide a lot of the old functionality that macOS Server used to provide.

The popular ones for macOS are Jamf and Mosyle. There are some other ones as well that are more cross-platform oriented, but both Jamf and Mosyle more or less cover the features that macOS Server provided for administration of a set of devices.

Tbh, I don't think Server was popular as a NAS service ever. The only thing I've ever used Server for was managing devices.

At least on AWS, you can parse the System Console Output. On the first boot, the box dumps its pub keys there. We have a tool that parses the output:

https://github.com/bitnomial/aws-ec2-knownhosts

Right now, this is pretty specific to our use of it, specifically our use with Terraform EC2 instances. We'd happily suggest changes to make it more generic. But you can see the parsing logic there.

Sure, I could imagine that is the case in fields like nuclear engineering. All the PEs I know are smart and have technical chops. Though, most of my PE friends are fairly young (early 30s) and are maybe on their way to that destination.

It's the only thing that most SaaS things charge for now-a-days. Slack, Dropbox, Github Enterprise, etc. They know that regulated businesses have requirements to have SSO and things like this, so they can charge out the nose for it. You can go for a very long time with paying little to nothing for most of these services until you need SSO.

You need to account for the delay to death in your model here. People don't die the second they're infected. Most of the people in that estimated infected number were infected in the last week. They couldn't possibly have died of the disease. I believe most epidemiological models have a infection to death delay factor to estimate death rate. Your mortality rate with ~300/100k~=flu is too low.

Adding a number of DisplayPort ports would be nice too.

Bitnomial | Software Engineer, Operations Engineer | Chicago | Onsite full-time | https://bitnomial.com

We’re building a Bitcoin derivatives exchange all written in Haskell. We use ansible and terraform for our operations automation. Trading industry experience is a plus.

We've also got a bunch of open source projects: https://github.com/bitnomial

Contact: [email protected]

Bitnomial | Software Engineer, Operations Engineer | Chicago | Onsite full-time | https://bitnomial.com

We’re building a Bitcoin derivatives exchange all written in Haskell. We use ansible and terraform for our operations automation. Trading industry experience is a plus.

We've also got a bunch of open source projects: https://github.com/bitnomial

Contact: [email protected]

Bitnomial | Software Engineer, Operations Engineer | Chicago | Onsite full-time | https://bitnomial.com

We’re building a Bitcoin derivatives exchange all written in Haskell. We use ansible and terraform for our operations automation. Trading industry experience is a plus.

We've also got a bunch of open source projects: https://github.com/bitnomial

Contact: [email protected]

Probably the investment round: https://techcrunch.com/2019/02/11/reddit-300-million/

I too have vim muscle memory in the terminal, so what I do is alias vim to emacsclient. It's actually really great! Terminal emacsclient with evil is basically indistinguishable from terminal vim.

The TCP and IP protocol specifications do not mention routing either. There are many routing algorithms possible, and many of them are used simultaneously. The same will be true for the lightning network. Lighting has a long way to go, but writing it off as a cute but useless experiment because of current limitations is short sighted.

Absolutely. Though, when people say cookies vs JWT, what they mean is:

Cookies: a simple session ID, a random number, stored in a cookie.

JWT: a JSON object stored in local storage that specifies authorization of some user that is authenticated by public key cryptography. JWTs can be configured in many ways, but this is what people usually mean because they want their sessions to be "stateless."

Way way more often than not, the "cookie" solution is better because it's far simpler. JWTs come with a tremendous amount of complexity with few benefits.

With respect to the snake-cased fields issue, it's actually not that hard to do that with Generic in Haskell.

  data Person = Person
       { personFirstName :: Text
       , personLastName  :: Text
       } deriving (Generic)

  instance ToJSON Person where
     toJSON = genericToJSON $ aesonPrefix snakeCase
  instance FromJSON Person where
     parseJSON = genericParseJSON $ aesonPrefix snakeCase

Which produces messages like:

  {
   "first_name": "John",
   "last_name": "Doe"
  }

Legal/compliance work is probably where this sort of service would be most useful.

Nah. That was just media insanity. Bitcoin functions just fine in the face of crazy politics. The whole point of it is to be unkillable.

True, I was wrong. Thank you for the correction.

> Innovation of bitcoin is proof of work, not a chain of blocks.

Proof of work was invented in the late 90s by Adam Back. The consensus algorithm using proof of work and a blockchain is what Bitcoin brought to the world.

I said "intentional hard-fork" for a reason. For everybody's reference, the bdb to leveldb hard-fork happened in early 2013. Everybody acted swiftly to correct the issue by downgrading to 0.7 if I recall correctly.

An accidental hard-fork is a completely different animal from an intentional contentious hard-fork where half of the network goes one way and the other half the other way for the foreseeable future.

This is a fantastic question, not naive at all, and it's really at the heart of what the debate is all about. This is a really complicated issue, hence all of the vitriolic discussion. I'm going to try to take a crack at it and fail. I will mostly be reiterating ideas that are from this[1]. I'll try to be brief, and you can read more from [1]. I am also very opinionated on this issue, and I will try to be as impartial as I can.

Something that's really confusing is that the word "fork" actually means at least two different things in the block-size debate context. The first is forking the bitcoin software, and the second is forking of the bitcoin blockchain/network. Bitcoin XT, Hearn's project, was the former, a software fork, that would cause a "hard-fork" in the blockchain. Hard-forks in Bitcoin are very dangerous. There has never been an intentional hard-fork of the Bitcoin blockchain since its inception 7 years ago.

There's a very difficult question of just simply, "how do hard-fork?" A hard-fork would separate the p2p network into two different networks with incompatible rules. A hasty hard-fork could very easily destroy people's money and bitcoin all together. Many, including myself, strongly disagree with Bitcoin XT's hard-fork procedure.

It's also not clear that this particular software fork, Bitcoin XT, is better. I'm not going to go into that issue here as it's extremely complicated. We have an alternative solution, segregated witness, which is effectively equivalent to Bitcoin XT's short-term plan implemented as a blockchain soft-fork. Soft-forks are significantly less dangerous as they do not segregate the network.

[1] https://bitcoin.org/en/bitcoin-core/capacity-increases-faq

The problem with this theory, as I see it, is identity. When you go through the body scan, they don't ask for your identification. Yes, they ask for ID before going to the security line, but there's a very difficult combinatorial problem with lining up IDs with bodyscans.

Also, I'm inclined to believe that the TSA is incompetent all the way up.

No, I don't. That seems really cool though! Thanks for pointing that out.

Groundhog is pretty awesome[1]. Persistent also works, but it does some wonky stuff on SQL databases. Acid-state is really neat! Of course, there's stuff like postgresql-simple, but that's not very type safe.

[1]https://www.fpcomplete.com/school/to-infinity-and-beyond/pic...

Edit: Also, esqueleto has a pretty okay looking hackage page[2], but I've never used esqueleto, so I don't really know.

[2]http://hackage.haskell.org/package/esqueleto

There are helpful tutorials for all of the things you've mentioned. I think that part of the problem is that people don't go looking for these things. If you want to write a backend for a web-app, there are three frameworks that are all mature: Snap, Yesod, and Happstack. There are tutorials, books, and documentation for all of these frameworks. If you want to do 3D graphics, there are some pretty straightforward bindings to OpenGL, again with tutorials and documentation. If you want to talk to a USB peripheral, there's the usb-safe. For databases, there are a myriad of options and tutorials for those.

The tutorials are all out there, but one is going to have to have a pretty solid grasp on Haskell before one can understand them, just like with any other language.