Additional NI Software Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 

NI Update Service should retrieve list of updates before notifying user

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.

7 Comments

after windows 8 installation i lost my multisim

 

Member

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.

Member

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

Linux Embedded / Kernel Hacker / BSP / Driver development / Systems engineering
Knight of NI

metux, that is where NI is going with NIPM.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
Member

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
Active Participant

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.

Member

@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 ? 

 

Linux Embedded / Kernel Hacker / BSP / Driver development / Systems engineering