voidlogic

Right but a Google L6 is a was probably a PE at the last Fortune 500 they worked for.

Why do you think the engine is beyond saving? I use Firefox everyday and have absolutely zero complaints...

You can still run firefox as normal app, and it's rock solid.

It would be more of apples to apples comparison to run it on the same setup you ran ab on. You can grab wrk here: https://github.com/wg/wrk Enjoy!

Hey, I live near you. Agree on multiple points. I doubt most people from the coasts would believe how good the food and drink scene in Winona and La Crosse is.

You are changing your view of the hard worker mindset based on experiences with a single individual?

Everyone I know in the API / CDN / Proxy space switched from using ab to wrk years ago for good reason. PSA: Please stop using ab and use wrk/wrk2. ab doesn't even support HTTP 1.1...

Most of your above list would be taken care just by sticking to Ubuntu on Thinkpads using gnome-session-flashback. Its basically a polished version of the same DE I have been using since 2004 and love... rock solid (not of the boot or HW issues you mentioned, etc). I spend like no time ever messing with it and its been that way since 2014, 2016?

I still don't understand why someone would want to use this over GOGS....

At my college all the dorms had a kitchen for residents to use in the basement... is this not normal?

I find Go's approach to be in the Goldilocks zone. Its not intrusive enough to slow me down (or guarantee correctness for that matter...) but its enough that I no longer need to save the multi-threading something I know needs to be multi-threaded for a second pass and very rarely have multi-threading issues or trouble debugging.

That being said, developers often have a bit of learning to get there, but that can greatly be accelerated by good team/mentor code review and discussion.

Also of note is having to terminate a single TCP/TLS connection per client vs one for every concurrent client request! Even if you are using a middle man like a CDN doing HTTP 1.1 pooling this is still reducing the established TCP/TLS connections by an order of magnitude or more.

This code should just call sha1.New(). If for some reason these allocations are a performance issue it is very simple to fix that will a little pooling:

    package main

    import (
        "crypto/sha1"
        "hash"
        "sync"
    )

    func main() {
        hasher := getHasher()
        defer poolHasher(hasher)
    }

    var hasherPool sync.Pool = sync.Pool{
        New: func() interface{} {
            return sha1.New()
        },
    }

    func getHasher() hash.Hash {
        return hasherPool.Get().(hash.Hash)
    }

    func poolHasher(hasher hash.Hash) {
        hasher.Reset()
        hasherPool.Put(hasher)
    }

Unfortunately there’s no way to know that one currently has Lyme disease unless the symptoms are close in time to a tick bite.

I thought you could test for bacterial nuclear material in the blood?

Edit found it: Its a PCR Assay: https://www.ncbi.nlm.nih.gov/pubmed/26469112

IMHO they should either just adopt Dave Cheney's errors package (https://github.com/pkg/errors) into the standard library or leave it as it is becoming the de-facto standard.

The parallel reddit thread seems to agree too: https://www.reddit.com/r/golang/comments/biexq0/go_113_xerro...

discover and purchase experience is abysmal.

  0. Home page
  1. Select product: https://puri.sm/products/
  2. View prod descs, select product: https://puri.sm/products/librem-13/
  3. Scroll down, view prod desc, click shop now
  4. At product configuration page: https://shop.puri.sm/shop/librem-13/

Your criticism (outside of complexity) of the suggestion may be unfounded, consider:

  Client: asks server for nonce
  Server: sends nonce
  ---- OR ----
  Nonce arrives with login page

  Client: sends HMAC(nonce + HMAC(username + password + appname) + Unix Epoch rounded to last 5 min block))

  Server: 
  1. gets response
  2. using username as key pulls HMAC(username + password + appname) from DB
  3. Computes HMAC(last nonce sent to username + DB HMAC + Unix Epoch rounded to last 5 min block)) and compares to user token
  4. last nonce is cleared

Store kiosk?

All the more reason to make the client side send HMAC(HMAC(username + password) + Unix Epoch rounded to last 5 min block)) over the wire in its POST to the auth endpoint.

All the transport encryption and DB encryption/hashing/salting won't protect you from this kind of logging mistake, but the above would.

P.S. There are ways to make the above even better by adding a nonce that has to be requested from the server before POST etc.

Power. Soon CF will be completely pervasive. CDN? Certs? DNS? Registrar? The are playing the long game for the win.

With all the brexit challanges, why not have a new referendum to "confirm the will of the people"? It seems doubtful it would pass this time, crisis averted?

Also, doesn't brexit basically guarantee Scottish independence? The Scotts were way more opposed to brexit than the English in the brexit referendum and their most recent independence referendum stated as a condition of the delay until the next independence referendum that the UK's relationship with the EU did not change? Is that right?

I wonder how this impact Fi, my understanding is Fi uses hangouts for all the VoIP/Wifi calling. I use Hangouts to handle all my text messages too...

I still use hangouts on my phone and via https://hangouts.google.com/ everyday.... what am I missing?

"There are many factors that affect performance."

Not only man different features contribute to performance but also that put performance depends so much on use-case. Two CPUs implementing the same arch might each win a benchmark that has a different instruction mix or memory access pattern, etc.

I agree. Its almost always more performant to intentionally build a system that to have characteristics that another system incrementally evolved to have. This is why rewritten software (if actually delivered) often performs better than the original, its usually this and not new framework X or new language Y that resulted in the win.

"On the other hand, that wastes cache memory and fetch bandwidth..."

This. One of the reasons why modern x86 processors have such strong performance is their external facing CISC interface effectively acts as memory compression while they are RISC on the inside. In many ways its a best of both worlds that was achieved through incremental evolution.

That would seem to incentivise staying below that threshold for a percentage of borrowers.

That only makes sense if its not implemented like taxes are. For example if when you exceed 50k and your repayment rate for the first 10k of income past 50k is 2%, and you earn 59k, you would take home $58,820. Why would you not want to take home this extra income.

Is of course is assuming it works like taxes in the US (which it probably does). The same kind of bad logic occurs in the US when people won't take a raise because they don't want to "jump tax brackets", but they don't realize you only pay the higher bracket rate on the income that was in that bracket!

The kicker is if a client connects to you via HTTP/2, you can't upgrade/hijack that session to be a websocket stream since the underlying TCP connection could be being shared by(used to multiplex) multiple HTTP requests/sessions. You have to take care to make sure the request ingress path from the client to the app is HTTP/1.1 end to end. That is something that is getting harder to do. Browsers use H/2 by default, more and more CDN do, more and more middle-ware does etc. The draft RFC I mentioned is a websocket upgrade mechanism for HTTP/2.

It seems like a glaring omission that this doesn't discuss the compatibility issues using websockets with HTTP/2, RFC8441 and Websockets vs SSE... Maybe this is an older article?

If you want someone from Podunk Kansas you could easily pay them a third as much as someone living in a major metro but yours will still be the best offer they have.

Not anymore, someone will be following the "locality doesn't matter mantra" and will outbid you. What you are saying might be more true for entry level or very generic skill sets. But if you are hiring top talent, you have to offer the same best offer everywhere, because if you won't then someone else will.