No, it doesn’t. In many other locales “mil” means thousand, unlike slang for million. This is why in finance, $5mm means five million dollars. Five mil mil. Five thousand thousand. Five million.
The graph shows a spike to around $5,000 per day ($5 mil por día). The entire dashboard is in USD, presented in a Spanish locale. That is also why the dollar sign is suffixed, the months are not capitalized, and why May has a dot after it, because it is abbreviated there (mayo).
Every programmer should understand locales even if they do not speak the language.
The Y axis of the graph which actually has relevant information. You are looking at a campaign page, and assuming those Colombian pesos are available to the author’s team.
When you said “the image” I thought you were looking at the right one, and I thought it odd you were off several orders of magnitude from what I assumed to be your misunderstanding. That explains that. I had to go back and find your figure.
apparently the $ sign has its origins in the spanish Peso, where the p and s were gradually being merged together in abbreviations.
futhermore the US Dollar itself stems from the Spanish Dollar:
"The U.S. dollar was directly based on the Spanish Milled Dollar when, in the Coinage Act of 1792, the first Mint Act, its value was fixed [..] as being "of the value of a Spanish milled dollar as the same is now current
But it's still potentially confusing, when stuff gets translated with no context for currency values. Especially, I imagine, if you don't know either Spanish or English.
Correct. They had it first, which is why I lightly check the “they use $ too? That’s confusing.” sentiment.
The Dutch, ever innovative in trade, can lay claim as a bigger influence on the word “dollar” and the currency form itself, however, and colonial Americans traded regularly in Dutch daalders (we still pronounce it that way, unlike doh-LAHR/doh-LAHR-ehss for the Spanish varieties). Daalders themselves were descendants of Bohemian thalers, as were Spanish dollars. We just borrowed the neighboring dollars when the time came, probably due to our foreign policy environment at the time, trade with Florida, and so on.
That's really my point. Not Americanism or whatever.
I mean we have kilograms, meters and seconds. And they're the same for every country.
But "$" (dollars and other currency units) means different things, depending on the context. Similarly for ounces, pounds, feet, gallons, etc. So you're left with constructions like "US $" or "USD" or "USD $" vs "Can $" or "CAD" or "CAD $". Just as with "avoirdupois ounce" vs "troy ounce", "US gallon" vs "imperial gallon", and so on.
So anyway, I always write "foo USD", "foo EUR", "foo mBTC" and so on. To avoid ambiguity.
Context. Canadian dollars use $ too, and you only see CAD near the border or when it isn’t clear. If I’m a Colombian using a Colombian site and pesos use $, I don’t need the context. Also, properly, you’d say 5 USD, not USD $5; the dollar sigil is then redundant.
There’s a bit of americentrism down the confusing line of thought, for what it’s worth.
That’s like saying “we hired the getaway driver, we can rob the bank now, right?” You’ve identified the first step of the plan. There are about nineteen more, and the theoretical network of conspirators required to accomplish this Oscar-winning screenplay would be quite large, which always spells trouble.
To that end, I’m amazed it took that long for the FBI to take down the network in the article. The more people who are read in to criminal activity, the risk exponentially increases, as anybody who has been on either end of investigative leverage can tell you. I’m stunned one person in the early days of this scam, particularly when it started involving colorful people, didn’t flip as a bargaining tool for other things they were into.
It's not uncommon to plant your own puppet as a president/prime minister of a country to make that country's policies favourable to you (CIA has done it numberous times). Planting a software developer cannot be harder.
One of the largest and most secretive companies in the world, the same one obsessed with preventing all leaks from exiting the company, the same one who produces ubiquitous devices with occasional national security implications that interest foreign governments, the same one who deals with serious IP problems in the very example nation you just happened to choose, has no thinking or plans around the well-known threats of industrial espionage or sabotage, is what you’re essentially saying. Consider for a moment whether that could be remotely plausible, and I think you’ll see it isn’t.
I didn't say they have no plans. Obviously they do. But unless you work for Apple, you don't know what they are.
Whatever their plans are, there is some number N of employees who could subvert those plans. It is legitimate to wonder how big that number is, and to note that there is no way for anyone outside of Apple to know.
There’s a meme out there, helpfully nudged along by Google, that Kubernetes is Borg “done right” and the successor. It’s even mentioned in this article. Neither of those things are true. Not even remotely. Please pass along to everyone to stop repeating the meme, because it distracts from Kubernetes’ true purpose, which is to lock people into GKE and force competitors to ship a Kubernetes runtime to compete. It’s partly the OpenStack playbook: if everybody runs the same platform, competition inherently drifts toward other aspects of the businesses, such as customer support. Seriously, I’m the only one who noticed the timing of Kubernetes and Google Cloud? Really? But Google shipped it, so now it has an ecosystem, and zealots who force entire teams onto it for zero upside and nonzero overhead, while the system that actually looks like Borg, the far superior to k8s HashiCorp Nomad, twiddles its thumbs with pretty much no mindshare.
For one, if Kubernetes were the successor to Borg, they wouldn’t have hobbled it architecturally as much as they have by marrying it to both Docker (kinda) and etcd, and deciding in the beginning to do every cluster mutation via external consensus in etcd, because you know, that’s a great idea and a classic Google design. Remember when Kubernetes pushed all job state changes through consensus and a flapping job could OOM etcd? I do too. Someone cynical could argue its fundamental architectural limitations are intentional. (I would argue simply that it didn’t have Paul Menage and most of the other names on the Borg paper working on it, to my knowledge.) I hear keyboards getting angry to yammer about how it just works. Not at seven-digit machine scale, it doesn’t, and never will. I’m happy it works for you. It’s a toy for a large fleet, which I’ll revisit in another point. Everyone I am aware of at Borg or Mesos scale has ruled out or failed with Kubernetes. No, really.
Relatedly, if Kubernetes were the successor to Borg, it’d be in C++. It just would be, and that’s not a language flame war. Ever wonder what percentage of systems at Google are C++? Ever wonder what that number does when you qualify “infrastructural”?
For two, Google containers aren’t an entire operating system, unlike Docker without crazy gymnastics. Seriously, this paragraph could be an essay. To paraphrase Jeremy Clarkson, Docker looks like a proper container system described over a blurry fax. Maybe we do need seventy probably-not-deduplicated copies of getty on every machine, and I’m yelling at clouds. I doubt it, and it reeks of “disk is cheap, fuck it.”
For three, Kubernetes is several orders of magnitude behind Borg and Omega, if that’s still alive, in terms of scheduling performance and maximum “cluster” size (I quote cluster because Google identifies a Borg unit as a cell, and a cluster means something else). This is not fixable in Kubernetes, in my reasonably informed opinion, without doing consensus differently. To my point, Borg does consensus and cluster state much differently, and you know what? It’s fine. Anybody who has used fauxmaster will back me up on that, and John Wilkes even said yup, every time we hit a limit we manage to double it with no end in sight. Why would that suddenly change? etcd remains Kubernetes’ Achilles heel, and this is why messaging around Kubernetes has gravitated toward smaller, targeted clusters. Bonus: if you find a bug in etcd make sure it loudly affects Kubernetes so it gets properly prioritized. Double bonus: someone was brave enough to suggest Consul in #1957 and children. Go read and sigh.
For four, when’s the last time you ran a 10,000+ node MapReduce on Kubernetes? Surprise, the underpinnings of Borg handle both batch and interactive with the exact same control plane, which is where the billions of containers a day number they occasionally talk about comes from. I mean, several JARs of glue might get you to Hadoop scheduling via Kubernetes, but that’s a much different animal than the platform thinking in terms of jobs with different interactivity requirements.
For five, half of Borg is the shit around it. Borg works because everything behaves the same. Everything is a Web server. Everything exposes /statusz. Everything builds and monitors the same way. Everything speaks the same RPC to each other. All of this is implemented by forcing production systems at Google to choose from four (as of my tenure) languages which are well tended and manicured by hundreds of people. Google has a larger C++ standard library team than many startups have engineers. Borg works because apps let it work. They’re not black boxes. Unlike Kubernetes.
Which brings me to point the sixth, which is that the reason you haven’t seen open source Borg is (a) they’re not moving off it, like, ever (I’d bet my season tickets on it), because significant parts of every production system and tool would have to change and (b) they can’t unravel Borg and the rest of the google3 codebase, because it’s so fundamental to the Google ecosystem and half of Borg’s magic is wrapped up in other projects within Google which they aren’t keen to show you.
Link to this answer next time anyone gets tempted to relay what they’ve heard about Borg and Kubernetes, please. For years I’ve watched this tale evolve until it’s barely recognizable as factual. Saying Kubernetes is Borg’s proper successor not only drastically insults Borg and the hundreds (thousands?) who have worked on it, it also calls to mind thinking of a cotton candy machine as the successor to the automobile. They’re that different.
There's a lot of FUD in here, like suggesting that Google wouldn't use something written in Go for this purpose (lol,) suggesting an open source platform that can span multiple clouds is an attempt to lock people into GKE (lol 2x,) and suggesting that Kubernetes is "married" to Docker (CNI? CRI?) or isn't extensible (the entire gRPC/REST API? custom resources? device plugins?)
People use Kubernetes for the ecosystem, the "shit around it." They even formed a foundation for the "shit around it" called the CNCF. And if you think all of that stuff is just for GKE lockin, maybe take a look at gRPC sometime.
I don't disagree that Kubernetes is not positioned to be a replacement for Borg, at least not for many years. It has a lot to go and the Storage API is indeed a sore spot for the Kubernetes project in general. But this realization is a very long walk from "Kubernetes was designed to lock people into GKE."
> I don't disagree that Kubernetes is not positioned to be a replacement for Borg
Good. Because that was my point, but the verbiage “don’t disagree” says a lot. We agree, except for the timeline. We will all be dead before Borg is replaced with Kubernetes. You can take that to the bank.
Kinda weird to fire up a throwaway, presumably to conceal your Google credentials, then attack a Xoogler who used to work on Borg SRE (alongside sjh under Peter Dahl, and long enough my NDA has long since lapsed) and has run Kubernetes since it was able to OOM as I described, for spreading FUD. The term FUD implies that I don’t know what I’m talking about and I’m making shit up, while I’m one of the few people, including presumably you, who can actually coherently comment on both.
It can only span multiple clouds now because other clouds had to ship Kubernetes. Remember the timeline: hello world, we made a container thing. Now we offer it as a service. Now Amazon does too. Oh, we are now multicloud. Your rebuttals are quite disingenuous, and casting them with a mocking aspersion doesn’t sell your point. It makes you come across nothing like you intend.
Get back on your real username and stop being offended I criticized Kubernetes. I know I’m one of the few who does, but there are legitimate concerns, and sharing them toward a “why Borg isn’t going anywhere” point is a weird hill for you to die on.
> Kinda weird to fire up a throwaway, presumably to conceal
> your Google credentials, then attack a Xoogler who used to
> work on Borg SRE (alongside sjh under Peter Dahl, and long
> enough my NDA has long since lapsed)
That's an interesting way to phrase it. I also worked on Borg SRE with Seth under Peter (for six years), and I don't remember anyone else with the same initials as me being present during that time. Just in case I was forgetting someone, I checked the Borg paper (https://storage.googleapis.com/pub-tools-public-publication-...) for the SRE credits section -- I remember all of them, but none had your ... personality.
Luckily, the very first hit for a search of [[ jsmthrowaway site:news.ycombinator.com ]] is your old comment from 2013 (https://news.ycombinator.com/item?id=6750805), in which you discuss being terminated after two months due to failing a background check. That explains why I couldn't remember you, but it doesn't explain why you think two months of reading "Borg 101" tutorials has given you meaningful insight into which parts of the Kubernetes implementation are difficult to scale.
I found this post on the HN front page. I take it somewhat personally because you're using an account with my initials, claiming to be a member of the team I used to work on, and using it to pretend knowledge of a system you used for less time than a typical intern.
Fair enough, but you said a whole lot of other crap that is very much misleading in my opinion, and I was addressing all of that.
>It can only span multiple clouds now because other clouds had to ship Kubernetes
See, this is the kind of thing that makes me treat this as FUD rather than just criticism. I was running Kubernetes on AWS long before Amazon offered a service for it. If Kubernetes wasn't open source and instead each cloud provider came up with their own implementation, would that have been better?
>Get back on your real username
No thanks. Doesn't take a rocket scientist to figure out why.
>Do I think Kubernetes is great if I have to build a CloudFormation thing to spin up all of its infrastructure and run it myself,
Yes.
>or would I rather pay big company to do it?
Also yes. The two aren't mutually exclusive.
Come on, you've used Borg. You wanna volunteer to going back to just using machines and VMs by hand, or worse, wiring up a complex and unreadable (Ansible|SaltStack|Chef|Puppet) playbook to set everything up?
No. This is why in the early days I was indeed running Kubernetes on AWS, by hand. As the tooling improved it only got better. I honestly wanted to have alternative choices, but Docker continually missed the point with Swarm and I just gave up on it.
>Your rebuttals are honestly more misleading, in my opinion, than my points, because you’re personally wrapped up in it and that’s coming across.
> It can only span multiple clouds now because other clouds had to ship Kubernetes.
This isn't true. People were running open-source Kubernetes on AWS and Azure before either provider had a hosted Kubernetes service. In fact back when GKE was the only hosted Kubernetes service, more companies were running Kubernetes on non-Google platforms than on GCP (https://www.cncf.io/blog/2017/12/06/cloud-native-technologie...).
Thanks so much for the detailed clarification! The k8s-as-Borg-successor meme is even perpetuated on the Borg paper, so I guess that's why I repeated it :P
If I may ask, is it primarily just reliance on publicly-available infrastructural pieces that hobbles K8s in terms of scalability? i.e. that the problem is more about ecosystem than architecture, because the industry just doesn't have things like (or as "good" as) Stubby and Chubby, and Google's basically never going to open-source/reimplement those?
Stubby and Chubby are not related to Borg's scalability.
The reason Kubernetes scalability was originally not so great was because it simply wasn't prioritized. We were more concerned with building a feature set that would drive adoption (and making sure the system was stable). Only once Kubernetes began to have serious users, did we start worrying about scalability. There have been a number of blog posts on the Kubernetes blog over the years about what we did to improve scalability, and how we measure it.
I'd encourage you to join the Kubernetes scalability SIG (https://github.com/kubernetes/community/tree/master/sig-scal...) to learn more about this topic. The SIG is always interested in understanding people's scalability requirements, and improving Kubernetes scalability beyond the current 5000 node "limit." (I put that in quotes because there's no performance cliff, it's just the maximum number of nodes you can run today if you want Kubernetes to meet the Kubernetes performance SLOs given the workload in the scalability tests.)
In this thread there is a repeated meme of "Borg is way more scalable than Kubernetes, and will always be so".
But this ignores a lot of the history of Borg. When Borg was first created, it was not nearly as scalable as its current incarnation. We hit scalability bugs and limitations all the time! (I was working on a team which was exploring the scalability limits of MapReduce, which was often very good at finding the limits in Borg and other systems it interacted with.)
Over the years many many Borg engineers have taken on many projects, both in solving bugs and rearchitecting major pieces of Borg with the intention of making it scale better (to run more jobs at once, utilize machines better, increase the degree of failure and performance isolation between jobs, and scale up to manage larger clusters of machines). Many of the lessons learned went into the design of Kubernetes, but Kubernetes is still much newer than Borg, which means it has fewer years of the "identify a scalability bug and squash it" feedback loop.
What is really needed to drive that loop is a major customer pushing the boundaries of scalability and identifying bugs. My guess (from the outside) is that the main users of Kubernetes have been pushing the limits in other directions, which has meant the team has been prioritizing other things (such as improving usability, and adding features) in their development efforts.
Borg will remain orders of magnitude beyond Kubernetes until Kubernetes is completely rearchitected. It’s not scalability bugs. It’s decisions regarding how the cluster maintains state that hamstring it, and that’s so fundamental to everything it’s not a find/squish loop.
As I said in my comment, those major customers (one personal experience, three anecdotally, eight or nine I’ve consulted with) have quietly ruled out Kubernetes, either by trying it or prying it apart and deciding not to try it. That feedback isn’t coming. At Borg scale, Kubernetes is very much considered a nonstarter.
> Borg will remain orders of magnitude beyond Kubernetes until Kubernetes is completely rearchitected. It’s not scalability bugs. It’s decisions regarding how the cluster maintains state that hamstring it, and that’s so fundamental to everything it’s not a find/squish loop.
Can you say more about this? Borgmaster uses Paxos for replicating checkpoint data, and etcd uses Raft for replicating the equivalent data, but these are really just two flavors of the same algorithm. I don't doubt that there are probably more efficient ways that Kubernetes could handle state (I don't claim to be an expert in that area), but I don't think they're approaches that would look any more like Borg than Kubernetes does.
If you're at liberty to do so, could you say what orchestrators the customers you mentioned chose in lieu of Kubernetes? What scale are they running at for a single cluster?
> It’s decisions regarding how the cluster maintains state that hamstring it
Jed, you keep repeating this like it's true, but it's not actually so. Here's an excerpt from Borg paper (which David co-authored btw ;-)):
> A single elected master per cell serves both as the Paxos leader and the state mutator, handling all operations that change the cell’s state, such as submitting a job or terminating a task on a machine.
And while we're at it, I don't know what it has to do with FauxMaster since it ran single replica and the passage about C++ is just pure fud.
It’s using Chubby for locking (it’s actually next sentence in that Borg paper) and some othe things not related to quorum that i cant go into. This is different from kube master that uses etcd for everything but in terms of performance it’s not a big deal because elections dont happen often (and youd be surprised how many ppl run k8s with a single master setup, even GKE)
I suppose that’s fair, but I’d argue against switching even being a primary motivation for anyone at Google, which is why I don’t think of it that way. You do have a point, though.
Without intimate knowledge of Borg, I can understand the successor discussion. With knowledge of what changed (i.e., was getting rid of borgmaster really that important to sacrifice that much perfwise?) I can’t even remotely fathom any purpose for Kubernetes other than what I’ve described. You, however, know far better than me. :)
[Disclaimers: I worked on Borg and Omega, and currently work on Kubernetes/GKE. Everything here is my personal opinion.]
There's a lot to unpack here, but I'll do my best.
I don't see Kubernetes locking people into GKE. There's an extensive conformance program (https://github.com/cncf/k8s-conformance) administered by the CNCF. AWS and Azure both have certified hosted Kubernetes offerings. Portability is in Google's best interest.
Go, Docker, and etcd were the best open-source technologies for the job at the time Kubernetes was created (and arguably still are). Open-sourcing Borg would have been impossible, due to its use of many Google-specific libraries (though a number of those have been open-sourced since then), and its close coupling to the Google production environment. Commenting more specifically on each of the pieces you mentioned:
* Go was chosen over C++ because, like C++, it is a systems language, but is much more accessible for building an open-source community.
* Docker was (and still is) by far the most popular container runtime, and the slimmer containerd makes it even more appropriate to serve as the container runtime for a system like Kubernetes. While it's true that in Borg the container runtime and "package" (container image) management systems are separate, the tradeoffs between packaging more in the image vs. pre-installing dependencies on the host are exactly the same as with Docker images. In any event, it's very feasible to build very slim Docker images (you definitely don't need getty in your image :-).
* You can read the reasons etcd was chosen in this recent comment (https://news.ycombinator.com/item?id=17476142) from a Red Hat employee who is one of the earliest contributors to Kubernetes and one of the most prolific. Regarding consensus, I didn't understand your comment; Borg uses Paxos and etcd uses Raft, but those are basically equivalent algorithms.
Regarding scalability, we do continuous scalability testing as part of the Kubernetes CI pipeline, at a cluster size of 5000 nodes. If you're interested in learning more, I'd encourage you to joint the scalability SIG (https://github.com/kubernetes/community/tree/master/sig-scal...). I'm not aware that "messaging around Kubernetes has gravitated toward smaller, targeted clusters." It's true that a lot of people do use small-ish clusters, but AFAICT that's not because of scalability limitations, but rather because (1) the hosted Kubernetes offerings make it so easy to spin up clusters on demand, and (2) until recently, Kubernetes was lacking critical multi-tenancy features that would allow, say, multiple teams within a company to safely share a cluster.
Regarding mixing batch and interactive/serving applications in a single cluster managed by a single control plane, this has been the intention of Kubernetes from the beginning. It's true that open-source batch systems like Hadoop and Spark have traditionally shipped with their own orchestrators/schedulers, but that's starting to change as Kubernetes becomes more popular, for example Spark now supports Kubernetes natively (https://kubernetes.io/blog/2018/03/apache-spark-23-with-nati...). In terms of features that enable batch and serving workloads to share a node and a cluster, Kubernetes has had the concept of QoS classes (https://kubernetes.io/docs/tasks/configure-pod-container/qua...) from the beginning, and as of the most recent Kubernetes release we now have priority/preemption (https://cloudplatform.googleblog.com/2018/02/get-the-most-ou...). QoS classes and priority/preemption are the two main concepts that allow batch and interactive/serving application to share nodes and clusters in Borg, and we now have them in Kubernetes.
On your fifth point, I agree that this is one of the strengths of the Google production environment, but Kubernetes is limited in how prescriptive it can be in dictating how people write applications, since we want Kubernetes to work with essentially any application. This is why we have, for example, extremely flexible liveness/readiness probes in Kubernetes (https://kubernetes.io/docs/tasks/configure-pod-container/con...) rather than the expectation that every application has a built-in web server that exports a predefined /statusz endpoint. That said, we have been more prescriptive in how to build Kubernetes control plane components (for example such components generally have /healthz endpoints and export Prometheus instrumentation according to the guidelines outlined at https://github.com/kubernetes/community/blob/master/contribu...). Over time as containers and the "cloud native" architecture become more popular, I think there will be more standardization in the ways you described when people see the benefits it provides in allowing them to plug in their app immediately to standard container ecosystems. To some extent Istio (https://github.com/istio/istio) is a step in that direction, and in some sense even better because it interposes transparently rather than requiring you to build your application a particular way.
For anyone interested in learning more about the evolution of cluster management systems at Google, I recommend this paper: https://ai.google/research/pubs/pub44843
While Kubernetes is definitely not the same codebase as Borg, I do think it's accurate to say that it is the descendant of Borg.
Dumb question: why does K8s use a centralized architecture like Borg, if the perf gains from an Omega-style shared-state scheduler decentralization (and maybe a Mesos-style two-level scheduler for batch with multiple frameworks) were already known, and Omega was already being folded back into Borg?
Is this related to (I'm assuming) the fact that K8s was originally architected "mostly" with service rather than batch in mind, and a monolithic scheduler was "good enough"?'
(Disclaimer: I haven't really followed K8s stuff in the last few months. How is multi-scheduler support for K8s nowadays, anyways?)
You can actually build an Omega vertical / Mesos framework architecture on Kubernetes, as described in this doc[1]. That doc pre-dated CRDs; the way you'd do it today is to build the application lifecycle management part of the framework using a CRD + controller, and run an application-specific scheduler (for pods created by that controller) alongside the default scheduler. The Kubernetes documentation page explaining how to run multiple/custom schedulers is here[2].
Borg only worked with a single scheduler, but Kubernetes allows you to build Omega/Mesos style verticals/frameworks and associated scheduling as user extensions to the control plane (as described above).
The rescheduler in Borg isn't a scheduler -- it just evicts pods, and then they go into the regular scheduler's pending queue and the regular scheduler decides where to schedule them. (At least that's how it worked at the time I left the project -- I assume it hasn't changed in this regard, but I don't know for sure.)
As a Xoogler myself, I have always wondered about the logic of "we can't open source X because it uses too many libraries and is too integrated". The obvious answer is, OK, open source the libraries and refactor the integrations to make them more flexible.
Reimplementing all of Borg from scratch seems crazy to me given the huge effort that went into it. Does Google want an open source cluster infrastructure or not? If yes, in what universe is it less effort to write a totally new one from scratch vs just progressively open sourcing things?
What's the size of the transitive dependency graph of Borg? 10MLOC? 50MLOC? 100MLOC? I have no idea. But it's a lot of code no matter what. Open sourcing that much code is a huge undertaking, unless you're just planning to throw it over the wall with no expectation of external people working on it.
On the other hand starting from scratch you get to grow the community and the codebase in lockstep.
It may be a large undertaking but yes, it's clearly still less work to release code that exists and build a community around it, than rewrite it all from scratch and also build a community around that too.
I've worked at Google for many years, and built open source communities based on code I've written from scratch several times. This is not an area I'm inexperienced in.
Generally Google software has a bottom up completely different approach to industry norm/standard. And the divergence started from Google’s very beginning.
Open sourcing system software from its internal state requires the same amount of work as rewriting, plus the effort to morph interfaces and internals to fit external needs, plus changes to internal workloads (assuming a unified stack internal & external).
I worked on google3 for years, most likely some of the code I wrote is still there. I've also done a lot of open source coding too. I'm quite familiar with the structure of google3 and it's not as different as you claim - Borg is a bunch of C++ libraries and programs that depend on each other, nothing magic about that.
So I completely disagree that open sourcing code is as hard as rewriting it from scratch. I think if you tried to argue that to anyone outside the Google bubble they'd think you were crazy. Writing code is hard work! Uploading it to github and creating some project structures around it is vastly less work.
I can't help wondering if this is engineers looking for new promotion-worthy projects.
To rebuttal your statements, I seem need to reveal a lot of technical details. You did not mention what type of software you were open sourcing when you were in Google. But it seems our overlap in knowledge is rather small.
I'll leave this open.
But I want to emphasize that what I stated are reasonable reasons for open sourcing by writing from scratch.
So it descends from Borg, which is fine. It does not replace Borg or indicate a Google strategy to replace Borg with Kubernetes, which was my entire point with supporting points on why, and explaining why you made the choices in Kubernetes that were made does not dispute that at all.
I note you were careful to use the word descendant, instead of my successor.
What I mean is simple: Borg has borgmaster. Kubernetes approached the same concept like a Web application, and now Kubernetes has an entire SIG to play on the same field as Borg. It was a poor architectural decision, along with many others in Kubernetes, but I wasn’t discussing that. I was discussing why Google won’t replace Borg with it.
The original joke involved simply the demonym for the servicemember and can be used with any service, and says “they teach sailors/soldiers/airmen to ...” and “well they teach marines/etc ...,” which would probably make you less confused by the joke. I heard that joke growing up involving airmen in both directions of the joke, and it was common until that film.
Relatedly, in case you don’t know this, never think you can call a marine a sailor based on the lineage you’re discussing here. Soldier is also only an appropriate term for someone in the Army, and there are countless films that screw this up. It’s less about the service and more of an identity.
Relatedly, in case you don’t know this, never think you can call a marine a sailor based on the lineage you’re discussing here.
As an Army veteran (who doesn't really like announcing himself as such when doesn't add to the discussion), quite well aware. I do-however make light-hearted jokes about Crayons from time-to-time ;) It's a fun sibling rivalry we have, the Army and the Corps.
Nobody should ever type the words “every citizen can generate cryptographic certificates” in that order. That’s like saying every citizen can compose jazz; technically true, which engineers love, but basically a lie that evidences how distant the engineering mindset is from an average person. Every citizen would instead reply what is a certificate? You mean the one I got for my marriage? Do I have to go wait in line for it? It involves my computer? Oh, you mean the computer that has spyware on it to lift the private key as soon as it’s created because TPM is still, you know, only deemed worthy of corporate security?
The gap between engineering and regular human beings continues to widen. Passwords remain difficult for people, but don’t let me stop the whiteboarding of a solution to the problem that will undoubtedly involve machine learning, Facebook OAuth, and GKE at some point. Add blockchain and pitch it to USDS before Thiel guts them and you’ve got yourself a hot party!
> Though I'm looking forward to the next cringeworthy cali startup meme.
Like half a cringeworthy Cali startup’s engineers spending their morning at Sightglass discussing an article about a password manager software being bought and lamenting whatever that future holds for Windows support, you mean? While their white male founder is parading around saying he’s making the world a better place with his singular vision about a grand Kubernetes mumble mumble, but entertaining a slow progression of M&A offers to cash out and just dump the entire company on Red Hat or Google to sort out because “serial entrepreneur” is a better title than ever hitting one nail or dropping one load of fries? Meanwhile, deadlines keep missing because the engineers are busy commenting on this article as noted, and arguing about JavaScript frameworks, and “WFH” every Tuesday and Thursday because commuting like everyone else for $175,000 cash is just too hard for precious snowflake engineers (seriously, have you smelled BART?), and God help anyone who schedules a 10am meeting. Remember, machine learning is this cycle’s password to get a YC check, and start your own journey to enriching your wealth and throwing a bunch of starry-eyed people who mystifyingly trusted you into whatever horrible business unit of whatever horrible corporation writes you the check you’ve earned on account of your complete lack of professional experience, biological fortunes, and who you’ve done cocaine and/or Bitcoin with most recently. Oh, and you were so busy making money, you didn’t stop to notice you’ve literally handed every nation state in the world citizenry command and control capabilities they only could have dreamed of before this stupid industry found a whiteboard and daringly ventured, “what if we put millions of dollars into letting Justin Bieber type 140 characters to fans, because that could never go wrong?”
Did you mean that kind of meme? If not, I may have some bad news.
You added an unnecessary level of indirection. The startups don’t have memes. They are the meme.
You could make that same comment without throwing 'white male' in the mix and it wouldn't have lost any substance.
I'll take 'my humans and I' style cringe over laboriously pointing out somebody's skin colour and gender as defining characteristics any day. There's nothing intelligent about it.
Actually, it’s a well-founded specific criticism (all of them are; no accidents there) of an underlying problem which contributes to the very concept I’m laboriously explaining. I note you didn’t refute my point at all, choosing instead to somewhat ironically call it unintelligent, and that you’re vaguely upset about it without a clear path to proving me wrong should speak more to what I’m trying to tell you.
I don't really see how most founders being white is a criticism - sure most of them are in a position of privilege, but that's because they're born into the upper classes and went to universities whose degrees cost more than most people's houses. The race factor comes from the fact that the disproportionate majority of wealthy families in the US are white. I mean, you don't see a proportional share of black or hispanic founders in Cali but you also don't see a proportional share of working-class white founders from the heartland either. We have the same thing in the UK.
I for one am having a hard time discerning your point, white males or no white males. The point between the lines seems to be that you wish you were getting rich.
I agree with most of the other criticisms except the identity stuff, because I'm disappointed by our industry. We were going to open up the world and make it a better place but it seems to have gone off the rails and become much more like the finance industry or other grim husks. The pretense remains but the reality is pretty cancerous. The platforms that are supposed to bring us together gave us depression, massive political division and put us under constant surveillance. The innovative ideas gave way to chasing fads for that sweet vc cash. The decentralised experimental currency is now penny stocks on steroids (although you could argue that was inevitable). I guess you could say the utopian vision died a sad death and not everyone wanted to see it go.
yeah that could well be the case. Either way, the prospect of your industry making a positive impact dying before your eyes is lame, whether it was ever really capable of that change or not.
That is the interpretation I’d expect from someone bought in, to only see people and their perspectives along an axis of wealth generation impetus. I’m sorry to disappoint, but also realize I’m probably incapable of explaining it to you, since my perspective is an imaginary component way off of your real number axis.
I’m boxed in a corner. If I explain it one way, you’ll interpret a Luddite sentiment. If I explain it another, you’ll interpret an affinity toward socialism. Yet another, and you’ll conclude I’m mentally challenged. I’m still working on vocalizing my detest for the valley and this audience in a form which is productive as opposed to punitive, so you’ll have to check back with me when I’ve matured that.
Well, the meme isn’t that far off. This community is starting to sound like the Soviet Union. Did everyone read that thread this morning and take it as a challenge or something? It’s not a goal to which to aspire.
These are lives you’re talking about here, kids, kids that happen to be currently sharing the same planet as you. Human beings are not figures on a balance sheet, and I lament anyone’s soul that would dispute me on that point. The pillars of this community sit on billions and get hospitals named after them, but some brown kids in a cave are a theoretical exercise to think about economics? They have memories. Families. Hopes. Should we debate your worth? What’s the figure where you are no longer considered worthwhile?
If I can’t meet you on something as fundamental as every life is worth saving, we simply aren’t having the same conversation, and I’ll be honest, your side gives me pause. And I see it far too often among people here who simply consider themselves pragmatic. Many throughout history have convinced themselves of their pragmatism, and we have all paid for it for centuries.
What unfortunate times to live in where the scions of high tech debate the value of individual lives in a far flung part of the world. This thread should disgust.
You are misreading me and the poster above. I was simply explaining what he meant and why it could be seen as rational.
The issue is really not as simple as you describe. Of course every life is worth saving, especially the lives of children. However, given a finite set of resources, would you rather save more or fewer children? The amount of money that goes into a long shot at saving a child with terminal cancer in the US would provide clean water and mosquito nets for many children in sub-Saharan Africa.
Am I saying that we should enforce this reallocation of resources? No. But I am saying that it is complicated.
Seriously, how many kids have died from thirst, starvation, or disease curable with under $10 of medication worldwide in the time it’s taken to try to rescue the kids from that cave?
But people love a spectacle. And heroics. So we just have to figure out how to make mosquito netting seem spectacularly heroic...
Sure, but was money diverted from mosquito netting programs to pay for this rescue? It certainly doesn't seem that way. Rather it the resources seem to have mostly come from the Thai military.
Why weren't you asking the Thai military to divert its resources to mosquito netting programs last week?
Surely that can't be true either or we'd be spending all our time saving people.
No the truth is more grim, we will save people until it costs more than we are willing to spend. Over time that threshold has increased with our wealth - but it remains in place as it must. Most people don't consciously think about it and it's upsetting to many.
It would because there are people we don't know how to save yet. The only way to save a cancer victim is to spend all of our time on cancer research. I think what most people mean is that they are willing to go to first order efforts to save people where immediately possible. But that is really just a form of triage and cost saving measure. Practicality still rules in the end.
I don't think I understand your comment. There are people we don't know how to save, but there are also people we do know how to save. The Against Malaria Foundation, for instance, claims that every ~$3k donated results in the prevention of the death of a child under the age of 5 (https://www.givewell.org/charities/amf#Cost_per_death_averte...).
I'm arguing against the idea that people truly believe "every life is worth saving" even by effective altruism advocates. Effective altruism is only arguing how we should ration the resources we've already allocated to helping people. It doesn't address the fact there is a quota at all.
For people who deal with this professionally the quota is defined monetarily. For the average person its an unconscious decision. But in all cases the amount of resources allocated to helping is not defined directly by the demand.
> Effective altruism is only arguing how we should ration the resources we've already allocated to helping people.
I'm not sure how to determine what "effective altruism" is arguing, but prominent EA advocates like Will MacAskill and Peter Singer are absolutely concerned with increasing the amount of money allocated to helping people. The conclusion of Singer's most famous argument is that we have a moral imperative to donate most of our money to saving the most lives. Even personally, both live modestly and donate most of their income.
None of the adjectives nor concepts you have applied to SMS apply, including the assertion that any number of clients can interconnect peacefully, that it is open, that it is a standard, that the steering of the technology is not actually done by the private surveillance companies you’ve mysteriously overlooked, not to mention how SMS is easier for law enforcement to acquire than a pack of cigarettes, because the carrier is sitting there waiting for a warrant on account of not angering the government that, you know, gave them spectrum and allowed them to exist in the first place.
Aside from all of that, good analysis.
Aware iPhone owners literally have the “oh, they’re green, looks like I have yet another plaintext compromise in my life and they’ll never figure out Signal” conversation with themselves every time they exchange numbers with someone new, and I’ve met more than one person who has remarked negatively to the person’s face that they are using SMS, including in a dating scenario as a dealbreaker. You might be the only person who likes it, aside from misguided parts of the Android community that praise SMS roughly like you do when discussing the lack of something like iMessage in that ecosystem, all without realizing the surveillance calculus you’ve correctly established is the real reason the carriers tie Google’s hands (even beyond Google going through messaging systems like socks).
You may not realize it, but on Android, Signal acts very similar to iMessages, pulling in your SMS & MMS so that you can seamlessly text regardless whether the other person is using Signal or not. Most features that come with the Android build just don't exist in Signal for iOS, or are delayed by a year, like Giphy support: https://signal.org/blog/signal-and-giphy-update/
Additionally, if someone is so petty as to consider not using iMessage as a dealbreaker, they likely have other issues that would cause a significant relationship to fail. More than a few families have one Apple user ID for 3+ phones, which makes iMessage effectively break (unless you want mom & dad to see Johnny's messages!).
At least buy OP a drink before psychoanalyzing their relationships that aggressively without any evidence to go on beside your cultural assumptions. Mere participation in this community is a beaming, reliable signal that you’re probably not Dr. Phil, so I’d suggest listening rather than explaining familial bond to someone you’ve never met.
If you said something like that to me in person, your evening would not go the way you think it would, and you’d find yourself in a conversation about your departure from the circumstances that allowed you to offer that perceived wisdom.
The graph shows a spike to around $5,000 per day ($5 mil por día). The entire dashboard is in USD, presented in a Spanish locale. That is also why the dollar sign is suffixed, the months are not capitalized, and why May has a dot after it, because it is abbreviated there (mayo).
Every programmer should understand locales even if they do not speak the language.