"If you offer to pay people to kill our people, we will do our best to make you lose this money" is IMO a pretty fair statement when published. Not only it calls the bluff of depending on mercenaries performing the Russian war machine duties, it might discourage them from doing that in the future, since the Ukrainian side is now going to use that money in defense while paying only the costs of their own covert operation.
Knowing how the Russians operate, they might decide to take the money back in skin.
They do tend to be pretty vindictive.
But it is kind of a funny concept, which is sort of an anodyne for an otherwise, really horrible situation. The Ukraine war is experiencing WWI-level casualties.
> Knowing how the Russians operate, they might decide to take the money back in skin.
>They do tend to be pretty vindictive.
I don't think it's any more risky for the Ukrainian military. They've already collectively been on Russia's wanted list for years and it's not like the country might get invaded by the Russian army any harder since it would have already happened long ago.
Good point. I was thinking of the individuals, as opposed to the institutions. The big guys will be protected, but the delivery people and analysts won’t be, on the Russian side, and the lower-level folks on the Ukrainian side could be selected for extra attention.
They are already at war. Russia clearly doesn't have any other hand to play, that's why they're offering a bounty.
Ukraine has nothing more to fear from Russia, because Russia doesn't have anything else to threaten them with apart from nukes, which also is not an option that will give them victory.
I've been thinking a lot about this kind of thing recently - and put a prototype up of htvend [1] that allows you to archive out dependencies during an image build. The idea being that if you have a mix of private/public dependencies that the upstream dependencies can be saved off locally as blobs allowing your build process to be able to be re-run in the future, even if the upstream assets become unavailable (as appears to be the case here).
Their Dockerfiles include things like download pre built binaries from $SECRET_BASEURL which is hosted by them, can still be found in git log though. I imagine it will go offline / have auth soon enough.
Or if you have a decent sized deployment in one of the clouds, it's extremely likely you'll already use their internal registry (eg AWS ECR). I know that we do. So it's just a case of setting up a few docker build projects in git that push to your own internal registry.
It is at the top of the announcement. This only affects OCI images, not source code "The source code for containers and Helm charts remains available on GitHub under the Apache 2.0 license."
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 tried to do brick sorting (because we have great detection and classification models at https://brickit.app/)
It turned out to be much more complex than I expected.
The biggest issue was grabbing. Typical approach for this type of task is to use vacuum suction actuator, but it does not work for Lego parts, because they have stubs and prevent suction from working.
Also there are issues of part separation.
We abandoned this idea, but I still hope that we can return and achieve something working some day.
One question about Brickit - the main usecase I and many many dads of Lego kids have is that our kids want to reassemble sets and we spend ages searching for these pieces. Yet Brickit works by identifying and recommending its own mini-set lists. Is this a usecase that is not in scope (because of business model) or is technically difficult or unsatisfactory in execution (colors, accuracy)?
The use case "let me reassemble all the parts that I have" is out of scope of Brickit app. It works explicitly with the contents of a single scan, that's why you see small ideas to build: it's just what fits into the parts you scanned.
But! We recognize the intent, and we have something in the works which will be released very soon, stay tuned!
My kids mixed up about 20-300 sets, some big ones, and it feels quite hopeless sorting them through. Any tips on how to untangle, or is it a hopeless cause? I do vision research and am mulling an AI based approach too.
Interesting, is there a possibility of something like class-action where iPhone owners sue Apple for restricting access to Fortnite? I bet there should be a plenty of angry gamers.
Probably it would be wiser not to brag about this one