My team is worried about that too. We've been a java and spring shop for years. We're looking at micronaut, it's similar enough.
When I had someone from another team take a look at broadcom and what they could do to spring, they said the licenses are permissive, it will be fine. Likely not that simple.
- Shorter support windows, with longer support available for purchase (VMWare actually introduced this, but Broadcom can weaponize it)
- Then Enterprise Spring, which has additional features
- Then some other license shenaningans.
Hazelcast recently made the move where CVE security updates are only released into the OSS ecosystem quarterly - whereas the enterprise model gets them as soon as they're ready. In OSS, you have to rebuild and patch yourself.
That's a special kind of evil, which has Broadcom DNA all over it.
They're still technically Avago Technologies, just wearing the name of Broadcom after the acquisition in 2015-2016. Not sure if there's much of Broadcom left, beyond the name and what IP they had at the time which was not sold off, like they did with the IoT related IPs.
Taking a bunch of projects and making containers and flexible helm charts for them is kind of an interesting model. It’s what Redhat and Canonical do with raw Linux packages; they charge for premium support and even patches or extended support.
I was going through one of my clusters, I have two bitnami uses and they are both ‘building blocks’ I use Trino, which uses a metastore which uses postgresql and then some other package uses redis. It seems like both postgresql and redis could/would have containers and charts to install their stuff, where it breaks is the postgresql guys probably want to support “current” and not 4 major releases back, which is kind of normal to see in the wild.
It is kind of an interesting model, I’d love it if rancher or openshift or someone started to seriously compete. Shipping a Kubernetes in a box is nice but if they started packaging up the building blocks, that’s huge too.
Bitnami started out (2010? definitely since 2014) distributing virtual machine images (e.g. preconfigured LAMP stack server) and somehow inherited the official kubernetes helm repo several years ago, which even then, I think we all saw the writing on the wall.
Broadcom has always been about pure evil (cough capitalism cough), you just haven't been affected by it before. Ask anyone who's worked with their hardware...
So
Others have already provided good answers. I wouldn't classify it as evil if all they did was to stop maintaining the images & charts, I recognise how much time, effort and money that takes. Companies and open source developers alike are free to say "We can no longer work on this".
The evil part is in outright breaking people's systems, in violation of the implicit agreement established by having something be public in the first place.
I know Broadcom inherited Bitnami as part of an acquisition and legally have no obligation to do anything, but ethically (which is why they are evil, not necessarily criminal) they absolutely have a duty to minimise the damage, which is 100% within their power & budget as others have pointed out.
And this is before you even consider all the work unpaid contributors have put into Bitnami over the years (myself included).
It's also entirely fine if they delete these images to me. But not with a week of time frame, as originally intended.
And sure, we can go ahead and discuss how this being free incurs no SLAs or guarantees. That's correct, but does not mean that such a short time frame is both rude and not a high quality of offering a service. If I look at how long it would take us to cancel a customer contract and off-board those...
And apparently it costs $9 to host this for another month? Sheesh.
I agree. We do have mirrors setup, we do have observability into the images we use across the infrastructure. This has concluded we only have a minor issue with this move, wonderfully.
But, just butting users with "Just do this good practice" or "Just do this NOW" still is an uphill battle and will usually not cause the best effect with users. We're currently doing this while moving our 2-3 artifactories into one. If we just shut this stuff off because "You should have more control with your builds", there'd be a riot.
And sure, some people will still fail the migration no matter what. But such time frames are still punishing any but the most professional companies.
That's all in all the work I consider a good operations team to do. Make a stink, provide a migration path, be noticeable, and push people off of the old stuff. Just breaking things because "you should have" is burning trust by the mile.
This is not an accurate characterization of what's generating the outrage
The Path to Outrage is actually:
1. Launch HN with MPL licensing, "we <3 Open Source!11"
2. (a few moments later) Onoz, engineers cost money and that sweet VC juice dries up
3. echo BuSL > LICENSE; git commit -am"License update"; blog about "safeguarding our customers" or whatever
4. shocked pikachu face when users, who starting using the open source product, and maybe even contributed bug fixes or suggestions on how to make the community product better, lose their minds about having the rug pulled out from under them
Contrast this with:
1. Launch HN, asking for money to pay for the product
2. Potential customers will evaluate if the product adds enough value for the money requested
There is no step 3 containing outrage because everyone was on the same page from the beginning
> 2. (a few moments later) Onoz, engineers cost money and that sweet VC juice dries up
>
> 3. echo BuSL > LICENSE; git commit -am"License update"; blog about "safeguarding our customers" or whatever
In this case, it's a lot more nefarious. My boss has a list of companies Broadcom has literally sucked dry for money regardless if the company will make it 2 more years. Pretty much everything maintained by VMWare Tanzu and VMWare has to be considered a business risk at this point.
And I maintain, I'm not even mad that the free images go away. I'm saying it's unprofessional and rude how they are being removed. Which however isn't surprising with Broadcom per the last point.
And sure, the answer is to do it all in-house. But the industry has saved a lot of manpower and made tremendous progress by not doing that and sharing effort for a long time.
> The evil part is in outright breaking people's systems, in violation of the implicit agreement established by having something be public in the first place.
Something, something, sticking your hand in a lawnmower and expecting it not to be cut off.
that's an assumption, but Broadcom is most likely using open source software in all of their apps. So they do have a moral to also give something back. So just saying it's fair that they don't want to provide something for free anymore isn't really all that fair.
Oh don't get me wrong, my claim is that they are not even clearing the absolute lowest bar when it comes to their stewardship of the Bitnami repositories: Do no harm.
The images are currently in Docker Hub. If $9/month (or $15, not 100% sure if $9 includes organizations) to keep those images available is too much for Bitnami I'm sure there are many organizations who wouldn't mind paying that bill for them (possibly even Docker Hub itself).
Broadcom is deciding to host it on their own registry and bear the associated cost of doing so. Not sure what this has to do with sponsoring network egress
I suspect this might be helpful for minor integration challenges or library upgrades like others have mentioned, but in my experience, the vast majority of Rust compilation issues fall into one of two buckets:
1. Typos, oversights (like when adding new enum variants), etc. All things which in most cases are solved with a single keystroke using non-LLM LSPs.
2. Wrong assumptions (on my part) about lifetimes, ownership, or overall architecture. All problems which I very much doubt an LLM will be able to reason about, because the problems usually lie in my understanding or modelling of the problem domain, not anything to do with the code itself.
I tried the same about a month ago and was unable to get anywhere, probably due to being very new to the custom keyboard scene and having only a very vague understanding of how qmk/rmk/vial/keymaps fit together. Thanks for writing this up, I might give it another go now!
The custom keyboard bubble is really deep and filled with many, many different kind of setups which makes research not really easy.
To get you started:
- QMK is probably the most mature firmware for non-wireless devices and widely used. Probably the best starting point to get in touch with all the different concepts of keymap layers, one-shot modifiers, hold-tap-mechanics, ...
- Via/Vial is based on QMK and simply tries to provide a GUI for instant and live configuration of the keyboard, instead of doing it by code.
- ZMK is also very stable and designed for wireless usage (battery consumption) but also REALLY complex because of the toolchain (at least in my opinion)
- RMK, KMK, ... are all different kind of firmwares trying to do something different or better or just in a different language like rust or python. Most of the time these kind of firmware expect some kind of "basic knowledge". So I would start with the classics QMK or ZMK.
Thanks for writing all this down! I've written a lot of Rust, which was why I was drawn to RMK initially, but ran into a lot of the same headaches as the author, but without the perseverance to resolve any of them.
I did manage to get QMK working eventually, but without VIA/L the prospect of having to flash the two parts of my Ferris Sweep every single time I wanted to fine tune it, and having already spent a lot of time just getting that far, completely burned me out on the project.
I think impact can have a big influence on mechanical hard drive longevity, so it could be that the way the ServerPartDeals drives were sourced, handled or shipped compromised them.
Postgres upgrades were actually annoying the last time I did, where I had to explicitly import data from a previous version into the new one, instead of the software just automatically detecting that the data was a version behind and doing whatever to upgrade the format.
This would probably not have been as big of a headache, if it wasn't because it was running in a container, and was deployed as part of a separate project, meaning CloudNativePG (which probably handles this for you) was not an option.
I think it is a reference to the Chernobyl mini-series, where the Dyatlov character responds to the news of the level of radioactive contamination as "Not great, not terrible", unaware that their measuring equipment is actually maxed out, hiding the true scale of the problem.
The Chernobyl mini-series is highly recommended. It is a classic example of how arrogance and stupidity are closely related. (Where stupidity is defines as knowing the correct thing to do, but ignoring the facts or available infomation.)
If anyone watches a TV show with the assumption that they are getting an accurate view of history, then I wish them luck in life, since they will probably need it.
Tell that to the people who were displaced because of the accident, which of course, is proven truth. The last part of your statement is petty, based on ignorance of how life itself is extremely difficult to report after the fact when facts are so easily denied.
That particular series was presented with very heavy emphasis on how "accurate" it was to real events, though, and many, many people thought it a documentary.
I set up a Talos bare metal cluster about a year ago, and documented the whole process on my website. Feel free to reach out if you have any questions!
I've only used Bottlerocket in relation to EKS, and even then my interaction with it was pretty limited so I have no idea how it fares as a standalone operating system.
My one big experience with it was the recent bug which (as I recall) attempted to harden the system by marking memory pages as no-execute, which caused virtual runtime languages like Java to basically break entirely when running on a node using this version of Bottlerocket.
It was fixed pretty quickly, but it did feel like a weird thing to slip through...
It is precisely the large impact on GDP that poses a threat to the host nation. When companies like Novo Nordisk are such a huge part of the economy, they can exert disproportionate influence on society itself.
Our economy is absolutely benefiting from Novo Nordisk's size right now, but if/when their demand weakens or they're out-competed, we're going to end up with a lot of unemployed biotechnicians and massive roads to Kalundborg which will need to be maintained.
I'd be very interested to know as well. Although the last time I attempted to run kanidm in a containerized fashion it left a lot to be desired.
The software is (perhaps expectedly) not really built to support semi-ephemeral lifetimes, so it took quite a few hacks to get it running in Kubernetes the last time I tried.
As I recall, the primary issue I had was with exposing the certman-provided Let's Encrypt certificates to the kanidm process inside the container in a reasonable fashion. I don't think I found an elegant way of signalling to the kanidm process that the certificates had been renewed and should be reloaded.
It's a shame that competition for this position has been ramping up lately.