nicpottier

Hah, thanks, learn something every day! https://www.merriam-webster.com/words-at-play/bury-the-lede-...

Though this is well written and I'm sure Sam is trying to set a tone of respect and appreciation of what is good in vgo so as to start on the right foot, he is also "burying the lead" in that he never gets to the point.

I think Russ did an unusually good job of explaining the ideas around vgo, grounded by using real world examples. He set a high bar there, but hopefully Sam adopts some of the same methods of very concrete examples to explain his criticisms.

As it stands this is an interesting piece of reading but is too high level and abstract in its criticism to be effective. Looking forward to future installments that hopefully that will make Sam's criticisms clear.

From what I can tell one piece of criticism is the inability of vgo to define incompatibilities. That is that if you know these versions won't work, you can say never allow that version in your dependency graph. I'd love to hear more examples of this in the real world. Since vgo dependencies are basically always "pinned" this seems like that not big a deal to me, but maybe I'm missing something. Perhaps this is something that occurs with having two of your dependencies having different dependencies on a third package and one of those works only with dep3@v1.2 and the other only works with dep3@v1.3 or somesuch.

Maybe there are ways around that or maybe that's not the actual problem (again, hope Sam explains more in the future). I think there is a really interesting element to MSV that will actually drive Go culture though (and I'm a big believer in the importance of the culture of a language) which I think may minimize the problems that Sam is talking about and for the betterment of the community.

As others have noted, I hope that Sam comes out with the rest of this series quickly so that the go community can commit do a direction sooner rather than later and move on to actually building this new ecosystem.

Thanks, that's a good start, though seems slightly Shopify specific. Also is this GDPR compliant?

I would hope that it works now, my worry is more will it still work without me buying new stuff in five years?

For those that have a bunch of home automation.. is it actually... good?

It strikes me as one of those things that is fun to set up, but probably breaks in weird ways every few months and you have to have a special kind of patience to deal with that. (not to mention a shared sense of patience from spouses etc..)

How reliable and stable is all this stuff? Can you really set this up and forget it and have it work reliably, ie, always? How often do these standards change? Am I going to have to reconfigure all my light switches after getting a new router for example? Or base my light purchasing decisions based on this?

Just curious, I'm intrigued, but having gone down this path in the past it feels more hobby than utility.

Err.. aren't these guys going to run into regulatory problems? You need a license to sell this in the US. Not to mention selling crypto with credit cards is a great way to go broke unless you own the keys like Coinbase does.

Also, why would you trust the keys they are sending you? Having someone else generate a wallet for you then sending it to you via a USB key sounds very very bad.

I don't get this.

The latter yes.

CTRL-N is apparently a shortcut for new? Nice thought but this runs into standard navigation supported in OS X and most Unixes of using CTRL-N to go down a line. Kind of hard wired for me to navigate text boxes using CTRL-N and CTRL-P so would recommend another shortcut.

Otherwise very neat!

> just want to have fun writing a fancy dependency graph solver

There is no graph solver, that's the whole point.

Not sure you are understanding the proposal completely. You are never automatically upgraded to a version, semantic or otherwise. The only time vgo "chooses" a version is when you first bring it into a project with `vgo get`, then it assumes you want to start with the latest major/minor/patch version.

From then on, you will be "pinned" to that version unless you explicitly choose to upgrade it via an update to your mod.go or a `vgo get -u`

As to putting even MORE in the import paths, I think the idea fits in with Tim Berners-Lee, just that non-major versions are like "edits" to the URLs rather than fundamental changes to the the content of a page. IE, you don't rename the URL in your case when you make a spelling mistake, same as not "renaming" your imports when you are just bringing in a patch release.

You can do 1), you just have make that an explicit dependency of your own. It just won't grab newest by default for sub-dependencies. So yes, you can pull the latest.

2) seems like a bit of a silly reason, if we all wanted to make everything work the same all the time we wouldn't make much progress or try anything new. Whether vgo's approach is correct or not we don't know yet, but saying that it isn't familiar isn't a good enough reason to not try it out.

To me, vgo matches what we already do in our python projects with a lot of dependencies. Pin everything in a freeze and upgrade on a schedule when we need to. We have seen far too many failures doing it any other way. (IE, using the "latest" of everything, which often either breaks semantic versioning and actually breaks or has subtle bugs that didn't exist before)

Correct, it will get the newest version that is actually tested against your dependencies, which is by design.

Why would you want to pull a version that is newer than the author of the library you depend on has actually tested with? You can of course force this in vgo, but having the default use the versions specified by the authors makes a whole lot more sense than just using the newest.

That was addressed in a firmware update. All systems will have vulnerabilities, the important bit is how the companies react. Trezor has been pretty great IMO in that respect and that all their stuff is open gives me a bit more confidence that it has been well attacked and patched.

https://blog.trezor.io/trezor-firmware-security-update-1-5-2...

I have both a Ledger and Trezor and would recommend the latter even before this vulnerability. Their Ether support is meh, but for BTC it just feels more solid and well thought out. That they are open source (hardware and software) and have been very responsive to attacks found also helps on the trust front.

Haven't played with the newer Model-T with a touchscreen, I'm talking about the original Trezor which I believe they have no plans to EOL.

Right, can you imagine a Sony RX100 with the post processing of a Pixel 2?

Then again, maybe we don't need that additional step and we are already at the point where your phone is enough: https://www.theverge.com/2018/3/9/17097696/pixel-2xl-geneva-...

Ahem. Single AWS instance does not equal single core.

See my earlier note, it is a bit apples to oranges. Redis is not optimized for throughput on a machine, it is optimized for throughput on a single core. And that property allows lots of interesting things due not having any parallelism.

They are different tools and they have different performance characteristics. My only point was that comparing against Redis is somewhat misguided due to those differing goals.

The comparison to Redis is in the 4th paragraph of the linked article. "The paper includes numbers showing it beating Redis by over 10x on a single AWS instance"

I'm sorry I didn't go read the original paper, but I thought reading the article qualified me to comment. Sorry dad.

I think you also misunderstood my point about Lua. Embedded Lua in Redis is so powerful BECAUSE it is single threaded, not because it is just snazzy to have an embedded language. That with the primitives Redis provides allows you to build your own domain specific data structures with their own custom semantics that just aren't possible in other systems without rolling your own. And you can do it simply.

That Anna is faster is great, but it comes with its own set of constraints, I don't think I would be wrong in saying that includes you not having exclusive access to the data while you are in an embedded script running on the store.

Being faster (in throughput) than Redis doesn't seem that difficult, Redis is mostly single core. But with that restriction comes the magical constraint that you can run Lua on that single core without having to think about race conditions or concurrency. For many complicated systems this is an incredible property and can provide incredible power. Yes, you may eventually outgrow Redis, but if you do then you are entering pretty crazy territory where you will likely need something custom anyways.

All that to say, that particular comparison feels a bit Apples and Oranges to me.

As someone who has backcountry skied in Washington for the past 15 years color me interested!

What are the weather inputs into the models and do you think that will capture enough? Wind transportation seems easy enough to think about but stuff like hoar frost seems harder to predict using available weather data, but maybe that's just clear cold days?

I do wonder as well whether the models should actually be regionally specific. Sure avy patterns are different but that likely falls out if you are basing it all on weather. IE, WA can act like CO when we have many weeks in a row of cold and vice versa during warm spells there.

Anyways, will be keeping an eye on this. Enabling places with no current forecast to have something at all is a noble goal, though I am skeptical that the recent WA deaths would have been prevented, that's just education and group dynamics sadly.

This seems like a clever move by Google to build a "write once, run anywhere" framework so that they can get some amount of apps running on their new mobile OS spike Fuschia. All they need to do is make Flutter compelling enough for Android developers to adopt it.

Since best practices these days is to generate new receive addresses and never reuse them this feels pretty painful to me. But I appreciate it is a hard problem and the desire to really track absolutely everything.

But those BTC have gone through so many wallets since I first got them that I really don't have a full record, so please add a way for me to say "no, this isn't a sell and no this isn't a buy" instead of requiring a full trace of every address I've ever touched.

Given how many people use offline wallets (in my case a paper wallet as well as a Trezor) seems like you need some way to let me mark transactions as "non sell" and "non buy" otherwise this really doesn't provide me much value.

I plugged in Coinbase out of curiosity as I do need to figure out some taxes here. I don't understand how these calculations are being done however. Seems to be taking cryptocurrency transfers as "selling" events, even though I was just moving to a non-coinbase account. This basically makes this useless for me to track my capital gains. Am I missing something?

Earlier in the feed they showed some ships that were presumably towing the drone out. I'm sure there are some that are within a mile or two.

To your second question, how about a camera on a boat closer in with a hard line to a boat farther out with the satellite connection? You act as if sending a video feed is an unsolvable problem despite them beaming living video through the rest of the mission when they are in space.

I do find that super weird. You would think one of the nearby ships would have a feed as well no?

Pretty sure they were, as at the very end they both dial into the same landing pad.

I'm actually really curious about this as well, as Stripe becoming a lightning node would be huge for the network as they have so many connectors, both to payers and payees.

I kind of see the endgame of Bitcoin being this and I'm super bullish about BTC becoming viable as a payment platform again in a much more interesting way than the other competitors. BTC will have the best of all worlds if LTC actually ends up working on top of it.

For anybody familiar with BTC the LTC papers is pretty easy reading: https://github.com/lightningnetwork/paper

It is a super neat idea in all respects and could enable a whole new class of companies that provide these payment channels, all with very clear economic incentives not to suck while also requiring no trust on behalf of the users.

These are definitely interesting, kind of have to build your house around one though.

We currently use a wood stove that uses a catalytic combuster, so actually reburns the smoke for even more heat. Silly efficiency and almost no particulate matter so passes even the most stringent environmental laws. Its actually one the greenest ways to heat a place like ours. (it only heats the main living area though, we use small space heaters for bedrooms downstairs)

There are a few, though perhaps things are changing up there: http://www.govtech.com/dc/articles/High-Capacity-Data-Center...

I have a winter cabin up in the mountains near Seattle, which so happens to have some of the cheapest electricity in the world. (there are quite a few cryptocurrency mines nearby) Though we generally heat the place using a modern, efficient wood stove, I've half seriously been pondering buying a few graphics cards and doing some Ethereum mining to heat the basement. If I wasn't a bit scared about it setting the place on fire I'd probably do it, but pretty sure I'd end up heating the place for free after a season.