5,668 karma · joined March 14, 2011
The Gigazone™, MN | Philadelphia, PA
Emailers, you can call me "swilson" at my work domain.
https://go.dev/ref/mod#minimal-version-selection https://research.swtch.com/vgo-mvs
Instead of a "lock" file, go includes a "sum" file, which basically tells you the checksums of the versions of the modules that were used during a build happened to be, so that you can download them from a central place later and ensure you are working from the same thing (so that any surreptitious changes are identified).
Agreed. ‘sendOnce’ implies something very specific in most async settings and, in this interview question, is being used to mean something rather different.
Coming in as a gray hair to fix their disaster definitely pays the bills.
Consider how painful that is going to be for Apple, and Roman, with how the current administration is abusing the DOJ.
The repercussions of this could be huge.
There's flaws with every approach, but I much prefer the approach where this sort of thing is treated as a public good, rather than as yet another soon-to-be walled garden.
The supposed "caching" of layers really doesn't work in practice unless you add a bunch of other infrastructure and third-party tooling to your build process. Getting truly incremental and reproducible layers into your build process is non-trivial, and the Dockerfile approach fails to take advantage of that work once you've done it.
I've had nothing but trouble with .local and .localhost. Specifically, .local is intended for other purposes (multicast DNS) and .localhost has a nasty habit of turning into just "localhost" and in some cases, resolvers don't like to allow that to point to anything other than 127.0.0.1.
More recently, I've stuck to following the advice of RFC 6762 and use an actual registered TLD for internal use, and then sub-domain from there. I don't use my "production" TLD, but some other, unrelated TLD. For example, if my company is named FOO and our corporate homepage is at foo.com, I'll have a separate TLD like bar.com that I'll use for app development (and sub-domain as dev.bar.com, qa.bar.com, and maybe otherqa.bar.com as needed for different environments). That helps avoid any weirdness around .localhost, works well in larger dev/qa environments that aren't running on 127.0.0.1, and allows me to do things like have an internal CA for TLS instead of using self-signed certs with all of their UX warts.
For "local network" stuff, I stick to ".internal" because that's now what IANA recommends. But I would distinguish between how I use ".internal" to mean "things on my local network" from "this is where my team deploys our QA environment", because we likely aren't on the same network as where that QA environment is located and my ".internal" might overlap with your ".internal", but the QA environment is shared.
Whether the scores are legit or not, the fact that this was such a botched disclosure process is not a good look for the Kubernetes project, of which this is a part.
Edit: According to [1], the team at Wiz show a responsible disclosure timeline. Seems like the Kubernetes project's process didn't work so well. If Wiz is accurately reporting what happened in their blog, these fixes (or the plan for them) was available a month ago, despite seemingly not having working PRs until today, after the security announcement?
Again, I really appreciate the work of the team to ship this, but this isn't a good look for the Kubernetes project itself.
[1] https://www.wiz.io/blog/ingress-nginx-kubernetes-vulnerabili...
I've never understood the love for Eddy Cue. Apple pundits all seem to love him. Personally, I am really unimpressed by everything he's done. My understanding is he's been really good at negotiating big contracts.
I just don't think his execution or vision are exciting and, as you are hinting at, I don't think his moral compass points in the right direction. That said, despite some early pushback, my understanding is that Schiller was ultimately on-board with holding to the 30% cut.
https://www.google.com/maps/place/Jack+the+Horse+Lake/@47.61...
I would generally agree that that's the "default".
However, there are cases where two sides of a market need an intermediary with which they can both independently transact, and a net benefit of that interaction is felt on both sides. The key is to construct the solution such that the intermediary depends on the goodwill of both sides of the market.
I think Kagi is somewhat flipping the script. By "taking" data from publishers for free, they are then selling it to readers at a cost. However, there is a trade off. Kagi needs to make sure publishers continue to make their content available so that it can be searchable, or used in their Assistant product. In order to do that, they need to do the opposite of what Google is doing by trying to sequester traffic on Google.com: Kagi's best interest is to make sure that they provide good value to both sides.
Indeed, using the Assistant product, the way it is structured, I very often find myself clicking through to the referenced original sources and not just consuming the summarized content.
How this evolves over time, from a product design standpoint, will be interesting to watch.
How do you propose that happens?
There is no irony.