NI Update Service should retrieve list of updates before notifying user

[Jeremy_Marquis]

The Update Service supposedly already checked in the background and found I needed updates.  

Yet when I say “view updates” it makes me wait on a progress bar while it checks for updates.  

And then when I click “Upgrades and Service Packs” it has to check AGAIN with another, extra-slow progress bar.

It should just do all the checking in the background, retrieve the full list of updates, and stop interrupting our work to wait on progress bars.

[afterwindows8instalationmymultisimisnotworking]

after windows 8 installation i lost my multisim

[EricR]

Thank you for your feedback.

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.

[metux]

Why not just properly packaging for the OS/Distro's package manager, like already done w/ thousands of other applications ?

[crossrulz]

metux, that is where NI is going with NIPM.

[metux]

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.

[JoshuaP]

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]

---

@Jeremy_Marquis

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 ?