-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
-
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
It's not the default, but Rust absolutely allows dynamic linking [1]. For example, Bevy encourages building the engine as a dynamic library during development to improve iteration turnaround times for the app code [2].
[1] https://doc.rust-lang.org/reference/linkage.html
[2] https://github.com/bevyengine/bevy/issues/791
I dealt with a situation like this for a ROS driver for a camera, where the proprietary SO was redistributable, but the headers and the rest of the vendor's "SDK" was not. The vendor clarified for me repeatedly that it would not be acceptable for us to re-host the SDK, that it was only accessible from behind a login portal on their own site.
The solution we eventually came to was downloading the SDK on each build, using credentials baked into the downloader script:
https://github.com/ros-drivers/pointgrey_camera_driver/blob/...
The vendor was fine with this approach, and it didn't violate their TOU, though it sure did cause a bunch of pain for the maintainers of the public ROS CI infrastructure, as there were various random failures which would pop up as a consequence of this approach.
I think eventually the vendor must have relented, as the current version of the package actually does still download at build time, but at least it downloads from a local location— though if that is permissable, I don't know why the headers themselves aren't just included in the git repo.
Shared libraries and dynamic linking make writing FFI wrappers in other languages possible. If every library were statically linked, I wouldn't be able to write things like this: https://github.com/mike-bourgeous/mb-sound-jackffi
Google's distroless containers attempt to fix this issue: https://github.com/GoogleContainerTools/distroless
To be honest, I haven't really tracked it— the product I work on dropped stereo vision in favour of RGBD, so I don't really know where it's landed. I suppose it's not a great sign that the current generation SDK still requires a login to access:
https://www.flir.ca/products/spinnaker-sdk/
And at least one spinnaker-based driver seems to have inherited the "download the SDK from elsewhere" approach, though who knows if that's due to genuine need or just cargo-culting forward what was implemented years ago in the flycapture driver:
https://github.com/neufieldrobotics/spinnaker_sdk_camera_dri...
The "proper" approach here would of course be for Open Robotics (the ROS maintainers) to pull the debs and host them on the official ROS repos, as they do for a number of other dependencies [1], but that clearly hasn't happened [2].
I think a lot of hardware vendors who cut their teeth in the totally locked down world of industrial controls/perception still think they're protecting some fantastic trade secret or whatever by behaving like this.
[1]: https://github.com/ros-infrastructure/reprepro-updater/tree/...
[2]: http://packages.ros.org/ros/ubuntu/pool/main/s/
To be honest, I haven't really tracked it— the product I work on dropped stereo vision in favour of RGBD, so I don't really know where it's landed. I suppose it's not a great sign that the current generation SDK still requires a login to access:
https://www.flir.ca/products/spinnaker-sdk/
And at least one spinnaker-based driver seems to have inherited the "download the SDK from elsewhere" approach, though who knows if that's due to genuine need or just cargo-culting forward what was implemented years ago in the flycapture driver:
https://github.com/neufieldrobotics/spinnaker_sdk_camera_dri...
The "proper" approach here would of course be for Open Robotics (the ROS maintainers) to pull the debs and host them on the official ROS repos, as they do for a number of other dependencies [1], but that clearly hasn't happened [2].
I think a lot of hardware vendors who cut their teeth in the totally locked down world of industrial controls/perception still think they're protecting some fantastic trade secret or whatever by behaving like this.
[1]: https://github.com/ros-infrastructure/reprepro-updater/tree/...
[2]: http://packages.ros.org/ros/ubuntu/pool/main/s/
To be honest, I haven't really tracked it— the product I work on dropped stereo vision in favour of RGBD, so I don't really know where it's landed. I suppose it's not a great sign that the current generation SDK still requires a login to access:
https://www.flir.ca/products/spinnaker-sdk/
And at least one spinnaker-based driver seems to have inherited the "download the SDK from elsewhere" approach, though who knows if that's due to genuine need or just cargo-culting forward what was implemented years ago in the flycapture driver:
https://github.com/neufieldrobotics/spinnaker_sdk_camera_dri...
The "proper" approach here would of course be for Open Robotics (the ROS maintainers) to pull the debs and host them on the official ROS repos, as they do for a number of other dependencies [1], but that clearly hasn't happened [2].
I think a lot of hardware vendors who cut their teeth in the totally locked down world of industrial controls/perception still think they're protecting some fantastic trade secret or whatever by behaving like this.
[1]: https://github.com/ros-infrastructure/reprepro-updater/tree/...
[2]: http://packages.ros.org/ros/ubuntu/pool/main/s/