I am afraid I don't have a formed opinion on the sigsum project yet.
Thanks for the pointer though, it indeed looks interesting, it might come handy once we start the effort of adding a transparent log (i.e rekor) to Chainloop.
>Nearly a decade later, new problems arose when Kubernetes (the operating system of the cloud) brought open-source collaboration to a new level.
I'd love to get more context to that statement to understand it better because as it is, it sounds as such an arbitrary statement that undermines the credibility of all the content below.
Kubernetes didn't brought open-source collaboration to a new level. No matter how relevant Kubernetes is today, it's just a drop in the huge ocean of OSS. Maybe level in this context refers to 'gitops' which many of us where doing years before the term was coined and without K8s involved. Or perhaps the author refers to the fact that most gitops K8s frameworks will work via polling which is a fundamental scalability flaw.
To try and steelman this line - the CNCF (a major force behind k8s) has indeed been a game-changer for OSS. It has built a way for OSS projects created by large enterprises to move towards vendor-neutral community governance.
IMO the way Kubernetes is built and maintained serves as a model for sustainable, enterprise-grade open source.
The introduction was indeed pretty cheesy. I read it and thought ‘I bet there will be a load of comments about the introduction instead of the article’ and then I read the rest of the article. Thankfully other comments did discuss the real content of the post.
This reads like a buzzword soup to me as well. All of the "ideas" presented are existing systems that author wants them in the source control software. Not sure why?
Also GitHub is the defacto monorepo? Since when you can fork/clone code in a monorepo? The whole point of monorepo is to avoid that!
To read this charitably, interpret that statement not to mean that kubernetes-the-software itself is the best gift to OSS collaboration ever, but rather that Kubernetes-the-project "brought open-source collaboration to a new level" in the context of working on kubernetes-the-software. I think that makes more sense, and certainly isn't as pompous.
OpenStack had similar levels of contribution at its peak and had much of the same solutions. I'm just guessing the author is newer to the game so might have missed out on 2010-2013 in the infrastructure space.
One of the cool things to come out of it was Zuul, which is a merge queue system similar to Bors and friends.
Kubernetes has it's roots in Omega which was a research project to explore improvements to Borg.
It was created/released as a direct response to increasing lock-in of AWS and Azure PaaS like services that were becoming an existential threat to GCP ever gaining any marketshare.
Unlike OpenStack it did actually manage to mostly achieve it's goal of preventing lock-in by creating a standardized API in which all distributions/managed-providers need to provide and actually certifying that they do. OpenStack failed in this regard because it was overrun by vendor interests too quickly and suffered poor governance. Additionally the leading vendors of the time simply ignored it because none of them offered a compatible API layer and none of them cared about any of the upstarts that did. Also it turned out very few people wanted to build their own IaaS if it would be incompatible with AWS and bursting would be awkward.
k8s successfully learnt from these mistakes.
So it's contributions are two-fold.
1) Single-handedly forced the other 2 major vendors to implement a standard API.
2) Created an infrastructure OSS ecosystem above this API layer that broadly has been successful with enterprise interests while abiding by the governance model set out by core k8s.
These alone make it a very successful project even if you disagree with the technical implementation/merits.
You've said a lot of things but none of these respond to the comment you're referring to.
> 1) Single-handedly forced the other 2 major vendors to implement a standard API.
I (and I'm sure you too, you seem intelligent) would be surprised if say EKS is anywhere close to ECS usage. k8s is considered so complex/poor Amazon sell ECS-on-prem.
It's the epitome of resume driven development - nobody uses k8s for any other reason except to say they use k8s.
What's your alternative for stuff that needs to run on more than one server for reliability or scale? I have been duct-taping HA solutions since the late nineties, it definitely wasn't prettier than Kubernetes. We are beyond the phase where we want to care about a physical server with a broken hard disk or power supply. Whether or not Kubernetes-the-software is the answer to the conceptualisation of a "computer" is beyond the point; there is a clear trend towards abstraction of computing hardware for good reasons, even for companies way smaller than the Googles and AWSes of this world.
How do you host your stuff on, say, GCP? App engine? Only 1 per project. Compute Engine? Basically a VPS. Cloud Run? Ok, good luck with stuff that requires long running requests or listening to events from a source different from Google Cloud Pub/Sub, because your instances are eventually going to scale down to 0 and not wake up if no HTTP requests are incoming, so basically not an options for microservices if you're rolling with a non-google event broker. Need to host other Kafka, Elastic search, or anything else non-trivially deployable? How do you do that?
Right now I'd use Pulumi, years ago I'd use Terraform, or the AWS API - I part of the first node AWS API client and part of App Engine before k8s existed. k8s didn't invent infra as code or auto provisioning capacity. The fact that it's advocates act like it did is why k8s is a DevOps meme.
> your instances are eventually going to scale down to 0 and not wake up if no HTTP requests are incoming
That's a good thing. I think you don't understand Serverless.
The thing you stated is that k8s allows people to easily deploy across different cloud providers due to lack of vendor lock in. k8s doesn't because nobody uses it for that - the cost of getting it tunning compared to simpler alternatives removes all value from the cross-platform abilities. That's why k8s is a DevOps meme.
Ecosystem-fatigue maybe? I don't know if there is an existing term for this but it's got more and more common and it's going to get a hell lot of more.
As a junior engineer (20+ years ago, for me), anything new is enjoyable. Damn we even enjoyed .NET, J2EE, Perl.. whatever crap. You name it. But today there are so many frameworks, paradigms, tools, services... and sad thing is in many cases the differences are nuance-grade which for senior engineers might become incredibly exhausting, at least in my opinion. "Why would I want to spend 6 months learning Vue if I can do this in React in 6 weeks?", "Why should I learn Rust if I just can do this in C++?"...
I think there are big differences in how industry evolved in the early twenties to today. I think today's evolution can feel rather disappointing.
Note: Spain is preferred for the engineering positions but open to any location for exceptional candidates. US and Spain are ok for the Product Manager position.
At VMware, we are hiring multiple positions to work on several products associated with the Bitnami brand. These products are mostly corporate oriented but have a profound impact in the content that gets generated for the Open Source catalog used by millions of developers in the world.
If you ever wanted to work with Open Source, this is one of the most exciting opportunities out there. Bitnami is one of the top Open Source publishers in the world. Some of our containers have been downloaded more than 1.5 billion times and usage is growing exponentially every month.
For coping with this task we have started an initiative to renew our internal supply chain, increasing its ability to scale and meet the incredible demand that we are having both from corporate customers and the ISV publishers.
Our stack is modern Java based. That is Java 16 (moving now to 17) + Spring Boot + Microservices. We run in AWS and Kubernetes and we practice Continuous Delivery. Our core is built around the principles of DDD with a centralised event bus that all micro services use to choreograph themselves. We believe in sound engineering practices and evolutionary architectures. Everyone in the team has a saying and there is no ivory tower leaders that impose thoughts.
We have several positions open. All of them are full-remote and aiming to hire senior high level pre-staff positions that would be able to move to Staff level in two/three years. The salary depends on the country and the level so it is hard to put a specific band there but it is along the lines of what you would expect from a top tech company: Country above-average base salary + stock + options + health insurance + stock purchase plans + wellbeing + food tickets + generous holidays.
I'm linking here some public openings that we have but if you have any more questions or want to ping me directly for help with the application don't hesitate reaching out to me at martinpe@vmware.com
I'm not sure if this is just my personal feeling but I would say that stealing intellectual property was sort of common at that time. Open source was not widely known, knowledge was scarce, communities were just ramping up and really anyone with lack of principles could pretty much steal anything and get away with it.
It happened to me a few times with online content I wrote. Essentially tutorials, articles, etc. around Open Source. Once my own company sent me a newsletter which contained one of my articles signed by another employee from a different place. It felt pretty weird.
The article says the story was from 2005. Open source was very much widely known at that time. Linux was 13 years old by then, and Sun themselves open sourced both DTrace and Solaris that same year.
Now I miss my 90s cheap MTB. I remember me as a teenager buying and setting up the bar ends. It felt so cool. For a kid it was like the ultimate performance improvement.
But well, right, they were so 90s. That wouldn't really fit at all with the current super posh MTBs out there.
Cyclocross and gravel bikes are the modern equivalent of the 90s MTB and ride very similarly. A bit tough and dangerous on downhills, just like the good ol days.
Or maybe it is just not obvious that the background waves are a visualization. I just was reading this thread after going to the website and thought "I didn't see any visualization either". Then went back to the website and noticed the background.
This post and the Leetcode post both today in HN are in the totally different extremes at hiring. Try to get to dissect the person's psyche or try to find the best algorithm-maker? Totally different ways of hiring. Is the right formula in between?
This article seems to take it on Redis as it unproperly supports this use case, but Redis does not seem to be a right choice for a cheap vertically scalable k-v store. I didn't know SSSD but really you could have chosen amongst many other k-v stores or even memcache with disk support.
I guess the point is that someone chose Redis and soon realized that RAM was not going to be the cheapest store for 500Gb of data. But that is not Redis' fault.
I think you should throw away everything and start from scratch sailing on an already solid platform. Whether that is a plugin for Office 365, a paid app for Smartsheet or Airtable or any other *already successful* platform.
From your submission, I think what you are failing to understand is that you are asking people/companies to move their excel app/reporting to random-joe-bloggs' platform. It's not about the marketing. Even with the best marketing in the world, as a buyer I would ask myself "where this is going to be in one year?", and well...
Pick a solid platform. Hundreds of thousands of buyers are already there, the technology is already there, and you are not asking them to rebase their business. You only need to pipe the solution to the problem. If there is such problem then marketing will be way easier with a solid ground.
Well, people were pretty quick to adopt AirTable, even when they were random-joe-bloggs themselves... The difference is that people trusted them because of who they were, and because of the distribution channels they had access to.
Yes and you could leverage all that by simply developing for that platform. Rather than trying to build a brand from scratch, which is extremely hard.
And don’t underestimate how hard it was for Airtable to get traction: you make it sound as if it was easy. Underneath the surface, the founders would tell you how hard it was.
I found that reading and the project itself fascinating but not sure about how solid the project/analysis is.