Anything and everything Amateur Radio and beyond. Heavily into Open Source and SDR, working on a multi band monitor and transmitter.
#geek #nerd #hamradio VK6FLAB #podcaster #australia #ITProfessional #voiceover #opentowork
No.
Bambu Studio is forked from PrusaSlicer, licensed under the AGPL.
PrusaSlicer is a fork of Slic3r, also licensed under the AGPL.
Next time the company will write their own code and not steal it from the community, or they’ll comply with the licence under which they’re building their business.
What’s particularly troubling is that this is not the first time that Bambu Labs has done this.
Milk comes in 1.5 litre bottles, there’s two of us, we have it in coffee, tea, omelets , and occasionally in porridge, we shop once a fortnight, you do the maths.
I would put them on the shelf, but they don’t fit standing up and on more than one occasion they have leaked when lying down, so the door is the least worst option.
Sometimes they’re visible from the other side of the room, other times you need either a magnifying glass and a bright light whilst holding the bottle upside down.
Yay … a solid argument!
Thank you.
Consider the amount of strength required to make either movement. It might turn out that one way requires more strength than the other.
s/see/watch/
I didn’t see any other video in relation to this.
As I understand it, the author of the AGPL has recently posted about software that’s including closed source modules and the person who was told to cease and desist has documented exactly what the issue is based entirely on Bambu Labs’ source code. There’s also discussion about reverse engineering.
I don’t know if any of that is new ground or not, as I said, this is the first video I watched on the topic, it randomly turned up in my feed.
I think that below is probably a fair summary, but I note that I’m a FOSS user and contributor and this is my opinion.
There is a case to be made that there is an AGPL violation here and the documented evidence and commentary is growing.
More people with knowledge on the subject are apparently weighing in.
As a software developer, I think that this case is important because there is a growing trend by companies and individuals to hide source code from the community, even if that software was originally licensed to them under an irrevocable licence. In this case, as I understand it, the Bambu Labs software is a fork of Prussia Slicer, which itself is a fork of Slic3r, all of which is licensed under the AGPL.
We buy milk every fortnight and the date ranges vary wildly, which results in expired milk if we’re not careful.
Welcome to the community!
Apparently the petition went up in November 2025 and has a year to get enough signatures. Last I saw it was near to the halfway point of acceptance.
I came across it because I saw a post announcing that Inkscape was supporting it.
https://inkscape.org/news/2026/05/13/inkscape-supports-german-petition-to-recognize-ope/
Basically two choices:
I faced pretty much the exact same choice, except I was given four of them, each with 8 GB of RAM.
Unfortunately they were two different hardware revisions, so the most I could achieve was two servers with 16 GB each.
They sound like a Jet taking off when powered up and the BIOS doesn’t support lower fan speeds.
Instead after months of deliberation I decided to go with a SFF Lenovo, 32 GB, 2 x 1 TB NVME, Ryzen 7, and bought this:
It’s whisper quiet and running Proxmox.
To get VM video passthrough to work I installed an extra video card, though, you could install a desktop on the host OS instead if you prefer.
The video card I used to fit inside is this:
CVE-2026-26956 - vm2: WASM Sandbox Escape (Node 25 only)
vm2 is an open source vm/sandbox for Node.js. In version 3.10.4, vm2 is vulnerable to full sandbox escape with arbitrary code execution. Attacker code inside VM.run() obtains host process object and runs host commands with zero host cooperation. This issue has been patched in version 3.10.5.
No idea. I have two accounts, one on Lemmy, one on Mastodon. Presumably somebody is mirroring this community to Mastodon, or perhaps the other way around, I’m not sure.
The issue is not packaging, it’s users circumventing security out of ignorance, willful or not, still ignorance.
As Linux gains popularity, the users will need to learn, often the hard way, how to go about installing stuff. Running a random script off the internet is not how it’s done.
Uhm … no.
Linux had permissions from day one, neither Windows nor Apple did until much more recently.
I use Apple, since there’s many versions of its OS and only¹ the one based on BSD has permissions.
The entire Linux ecosystem is permissions based, it’s baked into the kernel and while bugs continue to be discovered and patched, they’re visible to everyone, where that’s not the case with either Windows nor Apple.
Permissions aren’t new. Unix has had them from the early days, as have operating systems like VMS, BSD and OS/400 to name a few.
As for exploits, the level of user social engineering exploits is exploding with the growth of Linux, since most new users come from operating systems with poor security.
In my opinion Mac OS is hurting itself by making inexplicable security choices, causing pain where none is required, resulting in people actively disabling security to their own detriment.
As for actual exploits, they’re getting more and more ubiquitous since more and more operating systems are running the same code, think python, nginx, bash, etc.
Finally, I’d point out that your attempt at dispelling what you call a myth does not appear to be backed up by facts or sources.
I’ve been in this industry for over 40 years and while it’s far from perfect, I am comfortable stating that Linux is more secure than many operating systems and I suspect that it will continue to be the case for the foreseeable future.
I also note that it has a significantly larger user base than any other OS. Don’t believe me? Heard of Android, same Linux kernel.
¹ There was a brief A/UX hybrid OS that had permissions, based on Unix System V and BSD. It was discontinued in 1995.
Have a look at your AWS billing console, since data egress is charged and downloading to verify is considered egress.
AWS S3 supports data checksums where a checksum is calculated at AWS, which you can compare against a checksum that you calculate locally.
This is an article that goes into how it works, but I’ve not (yet) tested it, but I’ll be following in your footsteps pretty soon.
https://medium.com/@maureenosaghae86/check-the-integrity-of-data-in-amazon-s3-with-additional-checksums-3e51fe45f530
As an aside, make sure that versioning is OFF on your backup bucket unless you specifically require and understand it, because even when you delete objects, they persist as a previous, all but invisible, and charged(!), version.
My former backup software “helpfully” enabled versioning and I was left with a $600 monthly bill for six months while there was no actual backup being done due to a local hardware failure, until I figured out what was happening. I used that software for years and shudder to think just how much extra it actually cost.
I will note that while I had a catastrophic hardware failure, I didn’t lose any data.
Finally, if you’re storing data in Glacier, retrieval is charged at different rates, depending on timelines of access, so it might be that your backup software is using the slow tier to “save” you money.