pythonaut_16

Browser green threads could be amazing!

Specifically an Erlang/Elixir-ish actor async implementation

I think Jose and team have done a great job with this, especially judiciously limiting what features get added to the core language.

This is also an area where Elixir is benefiting greatly from the maturity and ongoing development of the Erlang VM. Elixir is, in a sense, simply a text based interface on top of the BEAM.

I think the opposite tends to be more helpful. The title should give you as much information as possible at a glance since it's likely to be seen in a list of commits or as part of the history of a file or line of code.

The more verbose details and ticket id should be in the body since I'm more likely to care about them once I've pulled up the commit to review in detail.

I agree. Two other points:

1) While more sites might be targeting Chrome now, the browsers and standards are generally more inter-operable now than they were in IE6 days. jQuery came from a time where each browser supported drastically different APIs. These days Chrome and Firefox generally support 80-90% of the same APIs, with generally only a few cutting edge features and edge cases differeing.

2) Microsoft adopting Chromium as its core is in direct contrast to IE6 days. There are now two big players building on Chromium instead of one. That could have never happened with proprietary IE6. Now there are two hands on the wheel of Chromium, so to speak. And if Google won't play ball with Microsoft, like you said, Microsoft can fork Chromium, but I imagine both Google and Microsoft want to avoid that if possible.

Isn't Zen 2 adding support for AVX512?

Unless that piece has some sort of IP beyond a license of the code being used they run a real risk of Microsoft deciding it's cheaper and easier just to rewrite their own version of that library.

Perhaps Microsoft adopting Chromium will be healthy for Chromium too then. I don't expect Microsoft to immediately keep pace with Google's browser teams but they should be able to contribute significantly to Chromium and help balance out the direction of the project.

Looks good! Thanks!

As an added benefit, the pages version loads much faster than loading GitHub itself!

They could at least set it up to use Github pages then.

Then you could access http://openblockchains.github.io/awesome-ico-truths

Could this be a useful model to apply to analytics and tracking?

Selective sampling is already common (run X diagnostic 10% of the time). Could you say to a user of your application "Hey, we are tracking these X parameters, but applying Y degrees of uncertainty to your individual data."

I'm not pro-tracking by any means, but would this be a reasonable improvement to users' privacy without first needing to convince companies to stop all tracking wholesale?

Which interestingly is a problem IPFS would solve, right? But IPFS potentially introduces other drawbacks.

It would be cool to able to build dual-distribution applications, where publicly available assets and content blobs (e.g. app.js) could be distributed in an immutable, cache-able manner, and server interactions and private assets could still be handled in a more traditional client/server way.

Perhaps then we might even be able to realize the original intent of including dependencies from a CDN, being able to share a cached version of React across websites.

(I'm not and IPFS advocate or detractor)

I was imagining a potentially offline scenario where the blocks are physically recorded (i.e printed) and attached to the package as some kind of barcode or QR code. I suppose you could also deal with a scenario where the digital record is primarily transported with the shipment as well.

A tamperproof log with certain commodity hardware might be easier than guaranteeing secure network access to every participant in the chain.

One example I've seen in the wild is Walmart investing in blockchain for food safety. This is me in a sense trying to reverse engineer that thought process/system to figure out what benefits it might bring.

Looks like the system I'm thinking of is roughly a Proof of Authority system (https://en.wikipedia.org/wiki/Proof-of-authority). Your point about blockchain being unnecessary here is one of the points brought up in the Wikipedia article under Comparisons.

So looking back at your post, I think the big difference is trusting someone's key isn't equivalent to trusting them. Trusting Alice's key just means I can trust that a statement signed by Alice's key was indeed signed/made by Alice.

The value of the system is that Bob cannot modify what Alice has said and signed. So the only place where Bob could lie is in his own block. Additionally, once Carlos signs his block, Bob and Alice can no longer change their statement either, so we're partly relying on Carlos to verify that he receives the package in the condition described by Bob's block.

One vulnerability I see is Carlos could just cut out Bob and fork the chain with his own block coming right after Alice. To counter that you could have each sender sign off on who they entrusted the package to (i.e. Alice signs her block/creates a block saying she gave the package to Bob).

So essentially the idea is to set up a system of untrusted participants whose identities can be verified/trusted. Bob might have an incentive to lie about who he received the package from or what the condition of the was package when he received it, but he doesn't have much incentive to let other people sign messages using his key.

I'm not sure as a system whether there is actual value or benefits here over other simpler solutions, it's just a fun thought experiment I've been doing to try and figure out scenarios where blockchains could provide real benefits over other systems.

What would you suggest as an alternative where each step still independently verifies all previous steps?

I guess you could just store it in a database and store the hashes and signatures as columns but again, that seems more like implementing a blockchain strategy using a traditional RDBMS.

*After your edit: It seems like the blockchain is still useful in this case as a series of signed statements where it can be (generally) verified that each signature was made by a certain entity at a certain point in the chain.

I think perhaps one effective use by a central entity is to have trust centralized but proof of work is distributed.

An example would be that I, as the central entity, know which public keys/key pairs I want to trust, and the proof of work is the owner of said key signing a given block with it. So as the central authority I can't unilaterally rewrite history, but I can unilaterally decide whether the chain is valid.

E.g. Alice wants to deliver a package to Dan by means of Bob and Carlos as couriers. So Alice signs the initial block using her public key and gives the package+signed block to Bob, who signs and gives to Carlos, who signs and gives the package to Dan. Dan can independently verify his trust in Alice, Bob, and Carlos's public keys and then be sure that the package was passed along in the manner recorded in the blockchain.

Except this is an actually helpful diagram that points you towards other solutions depending on what benefits you think a blockchain might give you, instead of an (unhelpful) outright dismissal.

Doesn't that somewhat depend on how you define a blockchain? Blockchain doesn't inherently require proof of work/stake/etc, just a chain where each block contains a hash of the previous block(s). Proof of work/stake just happens to be a popular implementation detail because of cryptocurrencies.

Has NASA developed reusable, landable rockets and then successfully landed 2 of 3 launched as a triple booster heavy rocket package?

Out of Musk's companies, SpaceX is the farthest from a hype circus. They are delivering on real science and engineering.

But they also make is easier to migrate to Windows. .NET Core is a similar play.

Microsoft can no longer rely on Windows alone to pull developers and products to Windows so instead they're trying to attract developers to build for any & every platform on Microsoft's stack and support Windows as a by product and maybe choose Azure as well.

So in a sense they've switched to a carrot model rather than a stick model.

The simplest answer is I am the only user currently so it doesn't matter. Even with users, a short down time to bring down the old images and bring up the new images should be manageable. If I ever got to a point where that wasn't sufficient then I would consider that project successful enough to merit investment into zero downtime strategies and probably its own VPS as well.

From a more technical side, I haven't seen an issue with Traefik when I take a container down and back up again. The only delay I would anticipate is when you bring a new service online for the first time and Traefik detects it and configures + fetches LetsEncrypt certs for it.

I personally use Docker combined with a $5 droplet on Digital Ocean. This makes it easy to spin up multiple applications and sites without worrying about conflicting dependencies, and docker-compose gives me most of the benefits of orchestration tools (e.g. Kubernetes) that actually matter for my small scale usage.

Also Traefik makes a nice load balancer for this uage

So much awful software and UX is made by taking a paper based process and directly recreating it as a digital process without re-evaluating the process itself.

Has the government "subsidized" SpaceX? AFAIK the government has been a consistent customer of SpaceX and they've leased facilities from NASA but it seems that overall they aren't being subsidized but rather patronized.

Well of course not, all of the ISP's routers were already bricked.

The ads then probably weren't good either. But they were certainly less pervasive and hostile.

I'm not sure exactly what made Ecto click for me, but once it did, it quickly became my favorite ORM/data mapper.

Have you read some of the Plataformatec blog posts about Ecto?

This seems like a place where physical security keys could've be useful.

Any invoice would be expected to be signed using a physical security key. The University or a trusted third party would have a list of vendor keys, signed by the university's master key.

Any request to change account details or for payments would require a new signed invoice. Then any user receiving such an email could easily see if the invoice had been signed by a person who can cryptographically prove they have a key that is trusted to be in the vendor's possession.

I don't think Go has better concurrency than Erlang, but go does have generally better raw performance. Ultimately I think both are good languages they just make different trade offs.

If I was designing a command line app I'd probably choose Go, if I was designing a web service I'd probably choose Elixir/Erlang. Of course those can easily flip; there are classes of command line apps where I might choose Elixir/Erlang and there are classes of web services where I might choose Go.

I can't speak to Clojure though.

All (graphical) user interfaces are a lie. The only real question is whether they're lying to benefit the user or not.

I think this is the wrong mindset.

A better one would be: "Hire good developers. You can invest in teaching them whatever technology your company uses and/or built."

Otherwise you end up with companies that hire good developers who don't know the tech stack and expect them to be 110% productive in one week with no investment from the company in training them. Then, even if the developer can keep up with demands they end up writing sub par code due to unfamiliarity with the tech stack.