Every time I download new Rhino version, the installer dumps three trash plugins: Faro USB digitizer, MicroScribe digitizer, and Romer digitizer. I have never used these digitizers and I do not need their plugins. I complained about these junk plugins a few years ago, but my bug report was ignored.
They are part of the Rhino installer. It is not a bug.
What percentage of Rhino users use any of these digitizers?
What percentage of users use Moray export?
The fact you don’t use something does not make it a bug or junk.
1 Like
hmm well in all honestly i am all for economic handling, if somebody needs these additions then downloading them from the packet manager could/should be optional, specifically if it is about these devices which i personally barely know, saw once in my university and for my work just never needed them. installing anything that one never uses (me currently included) is unfortunately clutter indeed. not chunk per se, but what is it good for…
that may sound dumb, but its like going to the shop and buying bananas and every time you do that you get a tin of hairwax (you might not even have hair), which you are forced to take with, otherwise you dont get the bananas. 
2 Likes
If you don’t like them, you can actually remove them yourself from your install, Rhino doesn’t care if they are there or not AFAIK…
1 Like
yes, from the deepest of my heart, i hate them 
but besides my emotional anticipation there really is no need to include extra data that tens of thousands download every single time someone updates this currently very bugged and neverending regressive piece of software in hope of seeing light at the end of the dark tunnel, adding to a data ping pong that in total over the decades Rhino already exists might be in fact quite a waste of energy. shameful that is, in a time of reconsideration and sustainability awareness.
That’s being comically dramatic.
You also seem to think that “plugins” are “add-ons.” That’s not how it works at all, lots of basic functionality–most of it?–is provided via “plugins,” and that’s done for the sake of providing robust plugin support.
1 Like
I always thought that if I put the bread in the toaster I „plug in“, if I put it on the toaster I „add on“ and if do both after another then I „add-in“.
Not sure what this tells me about my toast, but I think this has something to do with Continental breakfast…
that may only look like it, i assure you i am drastically serious about it.
i am not aware to think of it in any different aspect other than data and i could not care less how one would call it if it is about wasting resources, when the majority of users probably dont even know that its there and would never need it, it becomes unnecessary.
one may think of it as a few bits and bytes here and now for one download but the amount grows exponentially with every new user.
I think its mixing two problems. If you develop an app you want as much encapsulation as possible. You can achieve that on multiple levels. If your app supports plugin/add-ins, then the ultimate encapsulation can be reached by providing software components as plugins. This proves the plugin system and ensures one directional dependency. Of course McNeel can ship parts of their software as plugin, but it does not tell you if that plugin is mandatory or not. Somebody at McNeel decided that these software components should be part of the basic installation. Its hard to tell if it makes sense or not, but if your goal is to reduce the installer size, then you might remove other parts as well and provide them over the package manager. This however is twofold. What if you are within a highly-secure environment, you need this interface but you have no connection to the outside. You could argue that Rhino needs to ship a certain subset without the package manager, no matter if the majority of users never use them. Especially if you sold these features.
The other advantage of having a bunch of “native” plugins is that they can be updated individually without having to download a new version of the whole program. All the import/export modules are plugins for example.
Yes we need to conserve those bits for future generations, or to allow Google to keep up with the 4.3 PETABYTES of data that’s uploaded to YouTube every day.
I really hope not.
we cant force anybody to be more responsible nor let anybody understand, since it always starts with being ridiculous.
if the arguments make sense no comment on that of course, but if its about packages which are just sent for no further reason without being actually used that much, i would argue that tossing these over to the package manager might make more sense, yes maybe even more of these like yousay if they are not used.
maybe thats just me… when i was working on my first pc before i got macified, having windows 3.11 installed, i was bored riskily tossing everything into the bin from the system which i did not believe i ever would need to see if windows still runs, i just like it compact nowadays everthing gets hidden so much you cant even find the stuff so easy.
but (sorry to say so) reluctantly claiming this
like it is something that should just be accepted is maybe also not the right attitude. again we are tallking about something small, probably we will not see changes soon or at all because the developers have enough dirt up their sticks currently with the V8 mess they left us with to even think about making such microadjustment, but its these microadjustments one always deems non important that can make a huge impact in total, and its more than just a about these few bytes.
Rhino feels so much like a patchwork with so many patches that are anyhow sown together so that it just works that it might make sense to start entirely anew, old experience but fresh mind set and while iRhino is making a promising start at it, maybe we see something of that likes for Rhino itself one day.
Well, I like it small as well. But there is always a trade-off.
Another example:
For any modern C# application you have a couple of options. You could ship it self-contained, trimmed, minimal and since very recently natively compiled.
The most secure is self-contained, because it includes everything to run the app, but it makes even a simple console application 60mb+. If you trim the “Runtime”, you only include the Runtime/SDK functionality that really matters for your code. But this is dangerous, because it is possible through certain language features to call functionality indirectly (“Reflection”) which is not present then.
You can also assume the user needs to install the Runtime alone. This makes a simple console application less than 10mb. However, on many PC’s the users have not the rights to install the Net Runtime. This results in the fact that a user might have not the SDK installed, uses an older version or a too new version of it.
If you compile natively you can make it even smaller. But your code needs to support it. Many Runtime/SDK functionality is not ready to be natively compiled. For libraries this is even worse. On top of that, any plugin of Rhino might want to use other features of the Runtime.
I have seen many issues, because we ship our tooling without the Runtime. It works because we have a custom Installation Manager, and we are within one corporation and we know the right people in the IT department. Still having the wrong Runtime was one of the most prominent bug reports/support requests.
So what we will likely see, is that the modern Rhino installer ships with the .Net Core Runtime. Its just the most secure option. Don’t underestimate the waste of resources (especially human) by handling any problems of a non-self-contained distribution.
So in other words, there are very good arguments to distribute more than needed. However it is also true that we see a lot of practical dead code in mature apps.