The argument seems to take the leap from 'Ring is the wrong abstraction for what I want to do' (fair enough) and concludes 'Ring is inadequate, and therefore Clojure has a viability problem.'
Ring is explicitly designed to be web-server agnostic and therefore intentionally does not expose the full Jetty/Jakarta surface. Many using ring aren't using Jetty!
If your app requirements are specifically EE/Jetty-centric, then bypassing Ring may be entirely reasonable, but I don't see how that becomes an argument against Ring's design, much less against Clojure’s viability for enterprise applications...when enterprise means "serious business" not "Jakarta EE".
There are a few actual issues with Ring's design (that are in the issue tracker) I can think of when it comes to it's ability to express valid HTTP semantics. But "it doesn't OIDC" isn't one of them (that's sort of a category error?)
All that said... The charitable reading of "Clojure has a larger problem for its future [...] in which we can produce enterprise-grade web applications" is one where the "we" is limited to Derek's company/team, which yea, sounds like they need more Jetty/Java EE than Ring provides. But if the "we" is the Clojure community as a whole, then I would dissent.
Bamboo has been sketch and proprietary since the beginning. It's such a shame to see the maker community get sucked in (though I guess there is precedence wrt Fusion et.al.)
It was really depressing when I realized that people will buy a sketchy product which is hurting the community and makers of non-sketchy products because "its cheaper and its not like my purchase is gonna change things one way or another."
It is selfish and short sighted, and it leaves their future impoverished, but in the moment they "got a good deal."
It's not worth engaging in the debate. People have complained that Prusa printers are expensive since forever, even when the MK3 was objectively superior to the alternative models. They would rather buy a $200 Ender and spend a lifetime tinkering with it.
I think it's a bit iffy to argue that the bootloader code is covered by the GPLv3. In programs for standard computers running a big OS, the distinction lies in whether you are linking a library into your program. If the GPL code isn't a library but an external program, it isn't linking, and OK by the GPL. Now on to the bootloader code: in order to flash your device you have to put everything into a single image file. I guess the claim is that this process constitutes linking. But I don't think that is how most people think. Some possible arguments:
When linking, symbols pointing to addresses are involved. The main program calls functions in the library, and you end up with a whole program. On the other hand, a bootloader just does its thing and then jumps to a fixed address in the main program. The main program doesn't call anything in the bootloader. (Note, the Linux kernel has a special clause that explicitly allows the userland to programmatically interface with the kernel.)
I realize this sort of depends on the microcontroller toolchain. I'm familiar with a few, but not much with STM32 stuff. If the toolchain is dumb and implements the bootloader in a way that resembles linking, i.e. making it possible to resolve all the symbols in the bootloader from the main program then it could very well make the bootloader subject to the GPL.
Even as far as linking goes... If you're not actually deriving from the code in a copyright sense then the GPL is limited in what it can demand. The advice from the FSF on linking is not exactly unbiased. The part about the intimacy of the communication between pieces of code seems a lot more solidly based in copyright law.
> This allegedly violates the GPLv3 clause that requires the release of the source code for the entire work if they are combined to form a larger program in or on a storage or distribution medium, such as the flash memory of the STM32F407 micro-controller on the board, and more recently in the update images Prusa supplies
This makes 0 sense as presented here. The GPL explicitly distinguishes mere aggregation from combining in a way that makes it a larger program. Putting both the proprietary bootloader and the GPL OS on the same disk / in the same system makes 0 difference to whether the bootloader is covered by the GPL or not.
If this were true, then any phone, any PS5, any Linux laptop, and almost all consumer hardware would be in violation of the GPL (note that the wording quoted there is also part of the GPLv2, it's not GPLv3 specific).
Unfortunately this comment entirely misses the mark.
The reason this is such a big deal is precisely because it's not a sketchy product. For people who are using their FDM printers for more than just minifigs from thingiverse there's no proper alternative to Bambu. Their hardware and software is significantly ahead of the competition.
If you want to print engineering-grade plastics reliably and accurately you are going to need a Bambu device, or drop 5 figures on a commercial machine. Those are the alternatives. Very few other firms offer consistent, accurate, high temperature printing - and the few that do, don't have the software to manage vibrations, flow control and thousands of other parameters well enough to get consistent hiqh quality results.
Some examples: Prusa have the One+, and good software management. But the "heated chamber" is actually just a fan attached to the underside of the bed, which means that the chamber temperature is not consistent across the volume, leading to poor quality products. There's a few niche devices from people like Qidi, but they don't have the build and software quality to get reliable, repeatable results.
Overall if you're trying to solve actual problems with your FDM device, rather than messing around as a hobby you need a tool that just works, and that can handle materials like PA12, PET and PC. Bambu are really the only sensible choice for this. Yes, I'd be far far happier if the software was really FOSS (the encrypted non-user-readable logs enrage me!), but overall it's a tool not a hobby. I don't have a sensible alternative.
I appreciate where you're coming from, but I think you may have unintentionally made my point.
Try this: Change the context "Acme's Sunscreen which is made from killing an endangered fish, is significantly better than any other sunscreen out there, and because it is already on fish we know it doesn't hurt the ocean!" except the production of Acme Sunscreen is leading to the extinction of said fish in the future. Short term profits, long term loss, and perhaps a bet that at some point what ever it is about the fish that makes great sunscreen will be figured out.
Using FOSS requires (by license) that you give back your changes, which, when functional prevents a vendor from exploiting the work of a bunch of people they didn't pay, to make a product where they pay a few people to push it way past what the community offers. Whereas if they had been publishing their changes, then their product wouldn't be "significantly ahead" because everyone using the same slicer base code would be able to also use Bambu's improvements. But Bambu doesn't do that because why let the competitors take advantage of the work of people who they didn't compensate for that work. Hmmm?
Except that the software part of the "significantly ahead" is in the device firmware, not the slicer. And it's only the slicer that's at issue in this debate. If it were the slicer that provided all this advantage over the competition it'd have been copied years ago, so this is really nothing to do with my point at all.
Again, I'd be far happier if they followed the terms of the AGPL and provided source for their custom slicing extensions, but it wouldn't really move the needle very much for the competition.
You realize that the slicer has to talk to the firmware, and it is documenting the commands their firmware implements which makes the combination of slicer + firmware print right? The whole point of the AGPL on the slicer was to prevent people from having special sauce printer firmware, get all the work of the slicer for "free" and then make their combination better than everyone else's. So you publish the code the slicer uses to talk to your device and that lets someone else implement the same codes (if they choose too).
I think it's reached commodity status instead of community... 3D printing I mean. At that point only thing that matters is ease of use, price, and quality of the result. People who are not _in_ the community but use the tool.
This is exactly what people engaged in surveillance capitalism is trying to achieve. Sell hardware/software at a loss, push out the competition that does things legitimately and then continue there engagement in profiling everyone for profit.
I did a presentation[0] on this about a month back. If we want these situations to stop we need to work to inform the public and work towards getting people that care in positions of power.
You can't really spit in the hobby 3d printing world without hitting the community. I have coworkers who talk about their printers, filament choice, what they've printed recently, etc etc. I've been around hackerspaces with that behavior for over a decade, but it spontaneously showed up at work from a shared interest.
That community is where open source tech tends to come from.
I know the community well, I was challenging the assertion this hurts the community. On the contrary, better and cheaper printers help the community way more than the worries over software licensing. The average person doesn't care, they want a printer that works and doesn't cost much.
Its not only a licensing issue, but they abuse this closed source binary to lock away major features from other slicers (DRM, signature checks), hinder development, include anti-debugging, telemetry, encrypt logs and configs, etc.
And the stock plugin ships an unaligned atomic that triggers the kernel's split_lock detector on every modern Intel CPU. Startup stalls for 25-60 seconds while the kernel walks each trap; every Device-tab click hits it again. The workaround (sysctl kernel.split_lock_mitigate=0) degrades system-wide performance and still misbehaves in LAN-only mode. Reported to Bambu over a year ago and still open: bambulab/BambuStudio#8605.
Again, the average person does not care about any of that. They will use the Bambu slicer (if even, I bet many only print from their phones with the app). They aren't aware of, nor do they care about, anti-debugging, telemetry, encrypted logs, or anything of that nature. Most who do use the slicer will probably be on Windows, not Linux, and on an x86_64 machine. Why is any of this a surprise? It's an appliance, not something to hack on. It would be one thing if it was presented that way, like the Prusas, but it is explicitly sold as a turnkey machine. If you don't like that, you can buy a printer from one of their many competitors, or build a printer yourself, Bambu is not stopping you.
Is the product sketchy or just their practices from your point of view?
I think a valid view (not saying it's right) of this is: "some dorks in a country I don't inhabit gave away valuable code. I'm going to use it and I don't particularly care about what they think about it"
How much do you care about Chinese law? does that make you sketchy?
Inevitably the situation is the "sketch" here is that the vendor avoids a cost by creatively interpreting the requirements. It became famously difficult to buy a reliable PC power supply at one point because PSU vendors were all trying to cut costs and undercut each other. When there isn't a lot of market differentiation features, people differentiate on price. At NetApp we got more and more prescriptive in our contracts with motherboard OEMs because they would do silly things like "leave off 1/2 the bypass capacitors" which would then cause the filer to fail in some environments. And I get that "its just business"
It's an easy thing to avoid the costs associated with complying with FOSS licenses because they FOSS people don't come after you. So instead of having a person on staff who is making sure the company is compliant and updating the web site with source as it changes etc etc. You just don't do any of that and not only do you save money not paying that person you don't have to bother the web site people every time you do a software update. So from a manufacturer's perspective it's a win.
That said, Chinese vendors selling to Chinese customers following Chinese law. All good. Chinese vendors selling to US customers and not following US law, that's bad. I don't see how Chinese law would be part of that discussion.
Yes openly breaking Chinese law in a manner that is in breach of international convention or otherwise has wider consequences (breaking rules about keeping information from the party doesn't count unless I'm there: our privacy laws override) would make us sketchy. Can you name a company that has done that, or are you pulling an idea out of your hat because your argument otherwise lacks supporting facts/evidence?
What makes them particularly sketchy is the hypocracy: they fully understand the concept of IP and they are using/abusing it to try defend their semi-walled garden.
I blame the other 3d printer makers: Anycubic, Ender, Creality, etc.
Bambulab is far from the first player enter the market, or even the "budget" segment, but they still somehow captured it. Only till recently the others begin offering something that can compete with bambu's machine.
Turn out the demand for a good 3d printer, that you only need to do very basic tuning, and does not break your bank account, is very high. Who could've guessed ?
Some people like to use tools to make something possible/easy. Others like the tools themselves.
The Bambu printers, at the time of their release, were an incredibly superior pieces of hardware and software that was priced very very well and, this was a really big deal, worked fully right out of the box.
It was a pretty clear choice in either dicking around with the tools, or actually using the tool to make things. They caused a huge shift in the industry because it was silly to NOT buy a Bambu, if you wanted to actually make things.
I love open source software, but I also know that a team of focused, dedicated, high skill, engineers, who are financially motivated with big paychecks, to do well, will often do a better job making something proprietary than a bunch of volunteers doing it for fun, on the weekends. Ffs, we didn't get a half ass implementation (thanks to shite 8 bit boards everyone was using) of motion/vibration compensation in all the open source firmwares, a tech from the 1960's, until right before Bambu's release. It's still not available in most. Pressure compensation was still relatively new.
No they did not. Calibrating flow and pressure advance was entirely manual. Vibration compensation/input shaping did not exist until 2023 [1], and was also entirely manual. The Pursa XL (only thing remotely comparable) was over double the price [2], with the Core One (Bambu competitor) not coming out until 2024 [2]. Their MMU was a clusterfuck of tinkering [4], so when Bambu released the AMS, people were trying to figure out ways to get it to work on the Prusa! Even now, the new Prusa MMU alone is almost as much as a Bambu + AMS!.
Bambu shook the industry because it was better in all ways that mattered if you actually wanted to make something.
if you absolutely needed a huge multi color/material printer, sure, but a prusa i3 mkwhatever was entirely adequate for normal 3d printing out of the box
I have a Prusa i3 Mk3 and a Bambu P1S and I have to disagree. They are in entirely different leagues. The Prusa was a step change improvement from an Ender 3, and the Bambu is a step change from the Prusa i3 Mk3. It definitely depends on what you're printing, but I personally saw all my print failures on the Prusa pretty much go away overnight with Bambu.
Nope. You will get absolute shite prints if you skip the manual, eyeballed, first layer cals [1]. Bambu manual effort is a few seconds [2] of navigating a menu, then print. But, these cal's are NOT equivalent, with Bambu doing linear advance cal and input shaping (completely manual on i3).
Prusa being "adequate" (and expensive) is partly why Bambu now has 41% of the market, while Prusa has < 3% [3].
Setting aside printer capability, to a lot of users, wifi would be a top requirement for "working out of the box", and unfortunately i3 MK3S+ didn't have it before Bambu hit the market. On one hand, I understand how they ended up there, because their contemporary rivals Creality and Anycubic didn't include it either, and most of their userbase understood that they needed to run Octoprint on a Pi Zero or buy Prusa's wifi module. But on the other hand, if anyone did any bit of market research, they would realize this is quite an abrasive purchasing experience for a $10 wifi module. It just felt stingy.
Externalized costs are real. "Overpriced because it's built in the EU" implicitly argues that there are no fundamental differences between the labor conditions, environmental controls, and societal impact of the production process.
Agree so much! It's so interesting all the different use cases and interpretations of those use cases people have.
Like this self-hosted project aims for "simple deployment"/less infra, but I can't imagine how you end up at "use Cloudflare proprietary offerings" and reconcile that with "self hosted".
But if you host the node app yourself and point it at your own seaweedfs/minio/garage that's still more infra than node process+SQLite file.
Ironically as a Clojure developer I would really love a JDK native JSON library that we could wrap to avoid having to ship 3rd party JSON deps. Sort of like how java.net.http made things simpler.
The argument seems to take the leap from 'Ring is the wrong abstraction for what I want to do' (fair enough) and concludes 'Ring is inadequate, and therefore Clojure has a viability problem.'
Ring is explicitly designed to be web-server agnostic and therefore intentionally does not expose the full Jetty/Jakarta surface. Many using ring aren't using Jetty!
If your app requirements are specifically EE/Jetty-centric, then bypassing Ring may be entirely reasonable, but I don't see how that becomes an argument against Ring's design, much less against Clojure’s viability for enterprise applications...when enterprise means "serious business" not "Jakarta EE".
There are a few actual issues with Ring's design (that are in the issue tracker) I can think of when it comes to it's ability to express valid HTTP semantics. But "it doesn't OIDC" isn't one of them (that's sort of a category error?)
All that said... The charitable reading of "Clojure has a larger problem for its future [...] in which we can produce enterprise-grade web applications" is one where the "we" is limited to Derek's company/team, which yea, sounds like they need more Jetty/Java EE than Ring provides. But if the "we" is the Clojure community as a whole, then I would dissent.
reply