AGPLv3 still has the termination clause which is at least in the worst case (total failure to comply) entirely self-contained.
I'm not however convinced they are really in violation by calling a binary plugin. GPL itself does not forbid you from dynamically linking to or calling unrelated software. The network plugin is analogous to a device driver, it's not core part of the slicer.
GPL differentiates between a "Combined Work" and an "Aggregate":
> A compilation of a covered work with other separate and independent works, which are not by their nature extensions of the covered work, and which are not combined with it such as to form a larger program, in or on a volume of a storage or distribution medium, is called an "aggregate" if the compilation and its resulting copyright are not used to limit the access or legal rights of the compilation's users beyond what the individual works permit. Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate.
If they tried to add DRM to Bambu Studio and prevent you from replacing their blackbox with a different one then that would be where they would clearly go against the v3's TiVo provisions.
> GPL itself does not forbid you from dynamically linking
GPL does not contain the words "dynamically linking". That‘s just a common interpretation as a shortcut.
In this case there are arguments for the program-plugin communication to be "intimate" and as such falling under "derivative work". But it‘s easy to take the other side, as well.
I put the actual clause under, but let's forget the actual legal definition for a moment.
GPL license in spirit is about assuring the user freedoms. No user freedoms are limited in this case. You are free to modify and redistribute the software as you like. OrcaSlicer pulls changes from Bambu without any issues.
I don't think trying to enforce the license in this way, even if possible (which again I think if it was it would happen with Linux drivers long before), is the right thing to do anyway. All it's doing is painting the GPL as a liability to any business for no benefit.
well, right now Denuvo "remote attests" in a Play Integrity "MEETS_BASIC_INTEGRITY" sense that it has no hardware backing and relies on checking your runtime enviroment for signs of tampering manually and obfuscating said checks.
The endgame is certainly flexing the machinery that is being built up over the last 20 years and spawning a SEV-SNP container on your machine that cannot be debugged, inspected and modified in any way. I don't think this is possible as of writing though.
SEV-SNP would actually be a very good outcome. But the Intel equivalent does not exist on desktop SKUs. Meanwhile there's a campaign to make sure every "P"C has a TPM module.
Since I know how many of those businesses are run I'll let you in on the very obvious secret: there’s zero chance they have enough uplink to accommodate everyone using 100% of their bandwidth at the same time, and probably much less than that.
Residential network access is oversold as everything else.
The only difference with storage is there’s a theoretical maximum on how much a single person can use.
But you could just as well limit backup upload speed for similar effect. Having something about fair use in ToS is really not that different.
Residential ISPs don’t work financially unless you oversell peak time full-rate bandwidth. If you do things right, you oversell at a level that your customers don’t actually slow down. Even today, you won’t have 100% of customers using 100% of their full line rate 100% of the time.
Back in the late 1990s we could run a couple dozen 56k lines on a 1.544 Mbps backhaul. We could have those to the same extent today, but there’s still a ratio that works fine.
Yes, yes. We know. The business environment can't be arsed to maintain it's own integrity by actually building out the capacity they want to charge for. Everyone hides behind statistical multiplexing until the actuarial pants shitting event occurs. Then it's bail out time, or "We're sorry. We used all the money for executive bonuses!"
Building out for 100% of theoretical capacity makes no sense but you can still easily accommodate the small handful of power users with plenty to spare. Most ISPs will not drop or throttle users trying to get their money's worth if it’s fiber or similar. LTE of course that’s another thing.
That sort of horrible abuse only happens in areas where some provider has strict monopoly, but that’s an aberration and with Starlink’s availability there’s an upper bound nowadays.
My guess would be price. Shoppers probably got more sensitive to the price of a keyboard as the price of computers dropped, and approximately none of them were choosing between two computer-bundles at the store with any regard for keyboard quality.
Most people and companies just use the keyboard that shipped with the computer. I don't think noise is as much of an issue as people make it out be.
Marketing made up this story about linear switches being for gamers. So now every mechanical keyboard needs to make unnecessary noise and offer extra resistance for harder bottom out or you're not a serious typist.
But that's not inherent to the keyboard. Linear switches are not any louder than cheapo office high-profile membrane.
I'm not a gamer these days, but from what I've seen, the gamers like a different type of keyswitch than regular typists. Normal typists like a clicky keyswitch where it clicks with very little travel, and has plenty of travel after this to avoid bottoming out. (so, Cherry blue)
Gamers want mechanical keyswitches with no click at all. (Cherry brown I think)
This is the marketing mythos I was talking about. The best typist keyboard is regular linear switch. Typing without bottom out is impossible. Clicking is just audio. Of course most mechanisms of producing clicking mean some degree of tactility (added resistance), but any tactility bump you have to overcome means you come out on the other side with more force which means harder bottom out. The way to reduce bottom out force is to not have any resistance, which is what linear switch is.
The most popular type of switch is brown because it's essentially a linear switch that is not marketed towards gamers. It's just sad.
Cherry browns are more like an average mechanical switch (and not in a bad way - they're a good middle ground if you use your keyboard for different things). Gaming oriented keyboards would use different ones.
I find the resistance to be a hindrance when typing. Fastest typing speed and comfort for me is my thinkpad keyboard which uses scissor switches with a very low profile - you need less effort per keystroke!
Right, that's why I recommend linear switches. But they're marketed as a gaming switch and they don't deserve this harmful reputation. They're simply the only non-stupid type of switch.
Low profile scissors are a compromise. They are tactile but it's for once functional as it compensates for the obvious lack of travel. The result is a mediocre but still above average experience. You can type fast on them but with more fatigue than high-profile linear.
Marketers want you to believe there's at least three different distinct switch types for different purposes because they want to sell you the same keyboard twice or thrice. But in reality there's linear and stupid. And some of them make unnecessary noise. Some of them make really sweet nostalgia noises like Alps switches but it's still a worse typing experience.
Both noise and resistance is something where mechanical keyboards can provide all desired options with the right switch choice. Gaming-oriented mechanical keyboards tend to have particularly low activation forces.
There really isn't any reason not to choose one except for price - and that's a fair consideration if you're fine with rubber domes or other alternatives.
You really only need dirty_ratio/bytes and dirty_background_ratio/bytes set to something lower than default. It also makes your progress bars show values closer to reality, especially when copying from fast to slow media.
Some distros already do set lower defaults, e.g. pop os:
> You really only need dirty_ratio/bytes and dirty_background_ratio/bytes set to something lower than default.
The vm.swappiness=1 was very necessary for me as well, and made as much difference as the dirties you'd mentioned.
I usually run Linus' master kernels (as I look for regressions in certain subsystems) and I know there's been some recent changes to the MM subsystem so this may explain some of the necessity for me.
> All they would have to do to support this is add a checkout field "VAT number" that shows up on a pdf invoice.
If only it would be that simple :)
In EU you have different procedures for B2C and B2B transactions. For B2B you need to verify the VAT number in VIES system and it’s not responsive like 50% of the time. I swear Germans literally turn off their servers when they go to sleep. If a customer provides a VAT number the flow might take even 12h+ to verify it. If you can do that verification you can use 0% VAT rate but if not you need to use a different VAT rate.
For B2C you need to support several scenarios: if company is outside of EU it needs to register for IOSS, if it’s a EU company that sells to other EU countries it needs to register for OSS or in each EU country for VAT separately but also a mix of both is possible. You can decide to no register to OSS special procedure but then there’s a sales limit before you have to register and you need to track it. Otherwise, you need to maintain special OSS registry with sales records and three pieces of proof that customer is based in the member country. Some EU countries have XML invoices (Italy, Romania, Germany soon) or mandatory invoice APIs (Poland), of course there’s actually no common EU standard so it depends on where the company is based.
Finally you need to choose a VAT rate for that country and they also change occasionally, e.g. Slovakia, Romania and Estonia all changed their highest rate just last year.
This is the bare minimum you need to support. There’s a lot of edge cases, e.g. it matters what country you actually ship from, and if you use e.g. fulfillment there are special procedures for that as well, or if you resell in B2B there are chain transactions which have their own set of spaghetti rules.
Much of that is at least for my company handled by our accounting company. We just print the correct VAT on the invoice, and report the same VAT to the accountant and they take care of the rest. The shop/payment processor etc doesn't need to be integrated to any of it. Though I have to post-process Stripe's reports, as they refuse to include the used VAT rate in there, despite them knowing it. Stripe does try to sell the tax service to us, but I refuse.
You can simplify for your use case (only B2C or you refund VAT afterwards for B2B, you only ship from one location, custom invoicing), but that’s what it takes to implement it correctly on platform level.
I'm not however convinced they are really in violation by calling a binary plugin. GPL itself does not forbid you from dynamically linking to or calling unrelated software. The network plugin is analogous to a device driver, it's not core part of the slicer.
GPL differentiates between a "Combined Work" and an "Aggregate":
> A compilation of a covered work with other separate and independent works, which are not by their nature extensions of the covered work, and which are not combined with it such as to form a larger program, in or on a volume of a storage or distribution medium, is called an "aggregate" if the compilation and its resulting copyright are not used to limit the access or legal rights of the compilation's users beyond what the individual works permit. Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate.
If they tried to add DRM to Bambu Studio and prevent you from replacing their blackbox with a different one then that would be where they would clearly go against the v3's TiVo provisions.