aric

Unrealistic security should be the only reason to disapprove of a bitcoin ETF governed by the SEC. Not only is it poorly suited for reckless centralization by thousands of indirect investors, but bitcoin as a whole would be setup up for massive government retaliation once the keys are compromised. MtGox x 10,000.

I'd be surprised if they didn't. There's a markup at which it'd be very economical to be a broader registrar. Future upselling is worth pulling users away from other registrars. Some of them will compete against CloudFlare sooner or later. Google's headed that way.

Good move. I've been looking for a security-focused registrar. Will CloudFlare Registrar open its doors outside of an Enterprise plan?

It's no more philosophical than saying the alternative is proper. Uniformity of expectations seems more practical to me. In contrast, I wouldn't see an advantage in map ranges ever staying the same even per process. There's no reason to promote that reliance.

It is to prevent hash tables being relied on for order. Randomization was added so maps aren't treated as invariant. The behavior in a range of a map is no less correct to be changing (in Go) rather than unchanging (in other languages). In other words, invariant relative to what? It's not too important. It's one of numerous ways Go promotes clearer design, at least in my eyes, to have disorder represent unordered and order represent ordered.

You can mimic that syntax in Go. I don't recommend it but you'd only have to add a function.

    func it(n int) []struct{} {
        return make([]struct{}, n)
    }

    // ex. 1:
    for range it(10) { 
        fmt.Println(".")
    }

    // ex. 2:
    for i := range it(10) { 
        fmt.Println(i) 
    }

I can't think of any modern non-monopoly companies that have obtained global domination without a need to perpetually acquire niche competitors along the way. That's especially so as several companies (Netflix, Amazon, Apple, Google, and non-US players at large) vie for limited attention.

I left it on overnight once. It worked. The pixel re-stuck several times after so it took a few more sessions. It's been normal going on a few years. You might try rubbing the pixel area a bit and testing other stuck pixel fixing software.

Days convey immediacy and scale. "Today" and "same day" balance precision. If time between an exploit becoming known and fixed consistently happened in 100 seconds or less, 0-sec might sound ok. Come to think of it, 0-sec is a fitting pun.

Exploring past those gates into membership is rumored to have led to a cabal of artists and designers in the web's avant-garde scene. We may remember hell.com for what it represented. It was a rabbit hole that unsettled minds, unfurling beyond depths of a web people previously thought they knew, to cause wonder.

Hell.com was in a league of its own in this genre. Those were the days. It's fittingly tragic that it's now reduced to a landing page of ads.

If you wanted to do that:

   b := &a
   fmt.Println((*b)[0])