From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
The feature you are talking about was originally created because there may have been new updates posted between the time where the dialog is displayed, and the point where someone clicks on the button and launches NI Update Service. We wanted to minimize the chance that the list of updates available had changed so we decided to always refresh the list.
The point that you are making is a good one. We have recorded a task to add the following functionality in a future release. When the NI Update Service dialog is displayed, if the original dialog was displayed recently (within a few hours) we will use the existing list instead of refreshing the list.
In addition, in the next version of NI Update Service, we have been working to improve the overall performance. This will help address the "extra-slow progress bar" that you mentioned and also improve the overall experience of using NI Update Service.
Eric Reffett | Director, Product Management | 1.512.683.8165 | ni.com
There are only two ways to tell somebody thanks: Kudos and Marked Solutions Unofficial Forum Rules and Guidelines "Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
No, not yet another homebrewn, proprietary pseudo-package-manager, but instead use robost standard technology that's proven in rugged and complex environments for 20 years, like dpkg/apt.
IOW: use the distro/platform's native package management and provide repositories for that.
Linux Embedded / Kernel Hacker / BSP / Driver development / Systems engineering
Metux you do realize that dpkg/apt doesn't work on Windows and Windows doesn't include a good out of the box package manager like Linux?
The NI Package Manager does it best to reuse as much of the debian package and feed format as possible. We of course had to make some small changes based on how Windows and Linux treat file paths very differently and allow users to wrap packages around MSI in order to reuse existing 3rd party installers. We even use the same libsolv library for calculating dependencies.
In addition, on Linux RT we are moving to the native Open Embedded package manager opkg that also leverages the Debian package format, but is designed to run on embedded platforms.
Metux you do realize that dpkg/apt doesn't work on Windows and Windows doesn't include a good out of the box package manager like Linux?
There's a win32 port, called wpkg. OTOH, cygwin also has a complete package manager.
The NI Package Manager does it best to reuse as much of the debian package and feed format as possible. We of course had to make some small changes based on how Windows and Linux treat file paths very differently
Most of that should already be handled by mingw32 / cygwin base libs.
and allow users to wrap packages around MSI in order to reuse existing 3rd party installers.
MSI doesn't have much to do w/ package management - it's more a container format w/ some metadata for essentially calling installers. The whole concept of individual installers is the main problem - such things shouldn't exist at all.
Instead create a generic package management *once* and then only provide package repos - just like we're doing in Linux world for over 25 years. (yes: I've done that for even more strange platforms in the past)
In addition, on Linux RT we are moving to the native Open Embedded package manager opkg that also leverages the Debian package format, but is designed to run on embedded platforms.
"moving to" ... why didn't you use it from day one ?
anyways, the cRIOs are big enough to run a full dpkg/apt stack easily.
apropos: what about drivers for the cRIOs ?
Linux Embedded / Kernel Hacker / BSP / Driver development / Systems engineering