3,093 karma · joined October 10, 2016
---
C++ can remain irrational longer than you can remain sane.
---
There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.
- C. A. R. Hoare (RIP)
To clarify: sentence search got slightly better at the cost of keyword search. So the result is unusable garbage.
Because I am instead annoyed at all three.
Not necessarily my neighbours, but the companies selling this spyware.
The reliability is way better than GitHub's uptime.
Better even than my car's uptime.
You must work in telco.
99.9999% or it's unusable :P
That aside, sure, maybe Bambu were the first to make an affordable core XY machine. But, outside of China, we still don't have an affordable core XY machine by this definition.
So Bambu were the first Chinese company to take advantage of cheap Chinese manufacturing to stop making crappy Prusa i3 clones, crappy other things, or v slot Bowden crap (Ender 3, etc.).
They were the first to "clone"[0] some existing core XY designs and make a polished and affordable product.
Cool.
I am not saying its a bad thing, but do we need to applaud it when China repeatedly undercuts the rest of the world by not playing on the same playing field?
[0]: I say clone only because many of the "clones" Prusa complained about so much were only visually similar to the uninitiated and were otherwise quite distinct (and also much lower quality). The Bambu core XY designs look a lot like other more expensive core XY designs of the time. But really core XY isn't hard, the hard part is all the fine details, which every "clone" maker has to deal with inevitably.
Another aspect is that releasing something under copyleft without putting an identity behind it is toothless. Someone can copy it and now if you want to go after them, you need to out yourself anyway.
The core XY design that all manufacturers are now centering around has been around long before Bambu existed as a company.
Even if the unscrupulous entities cared about the license, they would just get their (already paid for) CAD person to reverse engineer every single necessary model over the course of a week. If an amateur like me can reliably do that in his spare time, imagine what a professional could do during an 8 hour shift.
But it doesn't matter either way because no unscrupulous entity is going to be dumb enough to publicly announce that they used the models to produce their clone.
If I manufacture a clone of a Prusa, there is no way for anyone to prove that I used the original 3D models. If it were possible to prove that, it would also be possible to "prove" that I copied 3D CAD models that I've never seen, which could put me in legal trouble. Reverse engineering is not a crime, and reverse engineering (and all the costs associated with manufacturing and prototyping[0]) likely _can_ reproduce a near identical Prusa printer.
As an aside, if you've seen the average Prusa clone, it's often quite far from the original design. Almost nobody 1:1 cloned Prusas back when that was a thing, because the Prusa design didn't cut corners. Those clones would often use designs which were probably derived from the original, and were unpublished. Why didn't Prusa go after them for this? He should have had just as much luck given that those manufacturers were potentially in breach of the GPL.
In summary, the OCL cannot actually stop clones, because if it did, we'd have some serious problems with our legal systems, prohibiting perfectly legal reverse engineering (irrespective of if the cloners did the reverse engineering or not).
It _only_ stops people who are honest enough to state that their designs are derived from Prusa's models. People who weren't a threat to begin with, and who now are voluntarily subscribing to legal issues if they ever felt like selling a Prusa modification without Prusa's approval.
The real deterrents are:
* Design complexity
* Extreme amounts of competition (almost nobody would buy a prusa clone these days unless they _wanted_ to have an almost broken printer to force them to learn how to make it work reliably). We have cheap, good, first party 3D printer designs.
[0]: To clarify, when I say prototyping, this needs to happen irrespective of if you reverse engineer or not. Once you have the models, which will be true to life, you still have to "reverse engineer" the tools/dies/materials/etc, for which Prusa sensibly does _not_ offer the models.
It only stops the honest people from doing that (and possibly much more, like manufacturing and selling replacement parts or mods).
Creating 3D models from existing products is relatively fast and easy. The hard parts have always been the actual design process, materials selection, and setting up the supply and manufacturing chain.
Prusa took what was practically a non-issue (cloning of their modern printers which have multiple custom parts and are overall not easy to clone cheaply anyway) and used it to restrict the freedoms of end users and small businesses while crying about how they are the victims.
I lost a lot of respect for Prusa when they came out with the OCL.
A damn patent would have been both more effective and less restrictive for reasonable commercial purposes.
You can relay bluetooth.
The problem is that while you might be able to trust the crypto, the government won't trust you to do the crypto entirely by yourself. And this introduces avenues for deanonymisation. Moreover, collusion between the government and the entity making the age check can also theoretically deanonimize.
It's a complicated problem.
We continue to seek a technological solution to a parenting problem.
But even so, hand placing 20 labels, editing them to say the right thing, then hand placing the entries, making sure the tab order is correct, you don't want to be doing that by hand. And it gets worse if you need to edit this in the future.
I am not saying this because I think it sounds stupid, I am saying this because I spent 4 years at an organization where this was the only method to do things and I _know_ for a fact that it is stupid and tedious. Given that we had the list of fields, if the language wasn't hot garbage, and the organization wasn't stuck in the past, we could have made it so 99% of fields on 99% of forms could have been placed automatically and cleanly saving literally months of development time in total.
We needed a complex UI for something which could not be done natively using this technology and I proved this to be true when I made a data driven UI in a fraction of the time it was taking to iterate on the legacy version which had 1/10 of the features.
UI preview tools are incredibly useful, hot reloading when doing UI work is, again, incredibly useful.
What nobody needs in their life is to meticulously hand place elements and align them only for the auto-resizing logic to fuck things up.
You want good abstractions which let you easily and quickly define UI elements and to define new composable widgets. So that you can declare in your code details of how things should be aligned with respect to each other, and leave final layout to more code which, if you are lucky, you might not even need to write.
For an example, check out jetpack compose. It's not completely flawless, but it truly isn't bad.
Maybe we're agreeing, I'm not quite sure. But rather than having a separate concept of mapping IDs to names, you really want a unified concept of both, so that when you namespace it, you can't namespace half of it by accident.
Moreover, you want to ideally make it impossible to only namespace it and not anything which is affected by it. e.g. the filesystem where permissions are governed by user and group IDs.
The way this is currently done is with UID/GID mapping, which unless it is a 1:1 mapping to the current user, has to be done with privileges. But this restriction is a hint that the abstraction is bad.
Really what you'd want is to have the ability to also include the concept of "file owner" in the umbrella of "user namespace", so that you can have a setup where files can have arbitrary attributes settable by a user to specify that they're owned by "root" inside the namespace but by <you> outside it.
I'd say the problem is a fundamental design issue at multiple levels of the stack, exacerbated by the need to maintain backwards compatibility.
Plan9 solves this entire problem (albeit with its own trade-offs) by unifying all abstractions in the filesystem (but nothing, of course, stops you from unifying things via some IPC/RPC/whatever protocol, the filesystem in Plan 9 is just a mount of a 9P fileserver).
You literally can't get into a situation like the one described here.
To clarify, the kernel doesn't (well, it gets complicated with things like NFSv4 but let's just ignore that since it doesn't really make or break my point) know anything about users or groups. It _only_ has the ability to manage some integers on a per-process basis and tie those into integers attached to files.
Assuming for now that we want to keep this like that, if you want to tie names to those numbers, you have to have some kind of database. If not by reading a config file, or by running some random code, or by some virtual file system (unless I misunderstood ?), what other options do you have?
Unix sockets have the same issue. There are abstract namespace sockets, but these don't exactly help solve the core problem, since now changing the network namespace can get you in the same trouble. This also covers any other kind of socket.
Even if the kernel did have the capacity to maintain this information, something would need to load it or back it, and that something could fall afoul of similar bugs.
> root should be restricted to executing/loading only a whitelist of executables/shared objects
It should already be possible to achieve this with IMA I believe?
> But then again, you'll need a allow_for_root(1) utility to maintain this whitelist, and people absolutely will call it in their setup scripts in all kinds of dubious manner.
You'd just keep the signing keys off the machine and either sign things off the host or sign them with presence detection and an HSM.
Broadly, it is just good training since you're normally _not_ going to have CAD drawings. If you do this enough, it becomes second nature, and with a 3D printer it's fast to make test prints which you can use to check your measurements against.
More specifically, it avoids having to wonder if you'd be breaching some law by using those CAD drawings to make a "derivative work". While there's nothing illegal about using precise tools to measure an existing product and create a CAD model. It's (apparently) a silly grey area to take measurements from a CAD representation of a product to make your own CAD model. It can be argued that you're just taking factual information from a reference and using it to produce your own design. But whenever you find yourself saying to yourself that something "can be argued" then you really need to take pause to consider if you want to find that out for yourself or avoid the problem entirely.
This is the same absurd nonsense that Prusa's "Open" Community License imposes. If I buy a Prusa 3D printer and I just carefully measure it (I don't find this that hard, and I am at best an amateur, consider what an experienced CAD designer could achieve with the right tools), I can create a 3D model of the printer and, as long as I've omitted any separable purely aesthetic elements, I own all rights to that 3D model.
Moreover, as long as there are no patents on the product, I can manufacture and sell it.
The hard part of cloning a product like a 3D printer or silent fan is not in getting the exact CAD model, it's in the choice and sourcing of materials, making the right tooling, finding places to make all the parts, etc.
There are also some secrets on how certain things are manufactured. But those either don't appear in the CAD model or can be easily omitted.
If manufacturers want to hand out CAD models of their products, they should do so under some highly permissive license, with only enough detail to actually aid in producing mods. The alternative where the license is restrictive, is that you're just giving out poisoned apples that solely restrict the freedoms of anyone who decides to take them.
It would have avoided the "running code as root" part, but it would still allow an attacker to control the result of the function call.
I mean, the problem being solved here isn't exactly a bad problem to try to solve. You either permanently hard-code `/etc/passwd` as the user database, and `/etc/resolv.conf` as the source of DNS server information, or you allow these to be handled in a more complex way (thus allowing YellowPages, LDAP, or whatever you can imagine).
And writing comprehensive tests for this behaviour is very difficult regardless of which language you are using.
I am all for rust rewrites of things. But in this case, these are mistakes which were encouraged by the lazy design of `std::fs` and the developers' lack of relevant experience.
And to clarify, I don't blame the developers for lacking the relevant experience. Working on such a project is precisely the right place to learn stuff like this.
I think it's an absurdly dumb move by Canonical to take this project and beta-test it on normal users' machines though…
And I don't think you can get there via this route. But good luck anyway, I would love to be proven wrong.
Disabling auto-indexing just makes it harder to spot the issue. (To clarify, also not a bad idea in principle, just not _the_ solution.) If the file is still there and can be downloaded, that's strictly something which should not be possible in the first place.
Yeah, of course, but I am not aware of any regular car which comes stock with such filters.
The point was really that lasting 22k miles longer than stock would be an unrealistic improvement for a filter for a normal car.
> You should replace the oil filter when it is no longer filtering.
I was specifically referring to manufacturer recommendations. Of course they're conservative, they also have to account for engine wear.
And yes, you are right that ideally you'd test. Although testing the filter from what I've seen is destructive, and there's a nontrivial turnaround time.
I'd disagree that following manufacturer recommendations is a waste of money though. As you say, testing is _more_ expensive. Engine damage is even more expensive. Replacing the filter on schedule is the economical choice.
It might be strictly a waste of resources, but that's a separate concern.
But to keep it concise: The core problem is that you are stating a truism in response to a famous counter-example to specifically that truism. The other problem being that you are stating a truism which everyone else is already familiar with.
Yes, I'm sure most people on this website have ran into seemingly bad design choices which made sense once they knew more context. But that doesn't mean that all bad design choices are like this.
Specifically dumb oil filter placement is an example of such a case where the _only_ legitimate justification is design cost saving for the manufacturer (re-using an existing design meant for a different car).
You can maybe argue that saving on design costs (and I guess also re-tooling costs) is a saving that gets passed onto the consumer. But that consumer is unlikely to feel like they're saving much money when cars depreciate faster than ice cubes in the desert, and when their oil change is 2+ times more expensive every 6 months. Really that cost savings will only really benefit the manufacturer (well, at least until they tarnish their reputation).