bonienl

My grand-dad transferred to my dad, and he in turn transferred to me ... but wait there weren't any computers in those days ... I only got wisdom

I think we are a bit derailing here, let's focus on the original question about (missing) packages and how to deal with that. I am open to suggestions

Yes, that is the way everyone did it before cache-only shares were implemented in v5. The drawback with hidden folders are that they are hidden. They won't appear when browsing folders over the network or through the GUI. Hidden folders may be a positive too, depends on your needs I use "Total Commander" and have the option enabled to show hidden files and folders, it is no inconvenience to me, but that's only me.

The same can be said for dockers, given time they will become rock solid. Like any newborn, it has to go through its paces ...

Folders starting with a dot (hidden) are not moved at all. It can be used as a mechanism to ensure folders stay on the cache drive.

Dockers are the new kid on the block and they certainly have to prove themselves. True they have high potential but time will tell. To be clear - I do believe Dockers is the right way forward. A short story: I had a system locking issue a while back because the docker image run out of space (my own mistake in making it too small), it could be simply solved by enlarging the image size, but this story shows that dockers - though they are 'safer' - can have impact on the system as a whole. I have seen only one real issue with the System Stats plugin, that is when running over an extended period it can fill up the /var/log file system. Not because of System Stats ill behaving but simply because a 1 month rotation and associated logs doesn't fit in the standard system allocation of 128MB. The email "issue" only came to surface after introducing the notifications system, it is actually harmless (but annoying). It exists since the inception of System Stats 4 years ago, but always went unnoticed. It's my believe that System Stats is one of the most stable plugins out there.

But it's an illusion to think that "non-app" plugins never require additional packages. E.g. the Dynamix Stats plugin uses the package "sysstats", eventhough it is considered a GUI enhancement.

One way to mitigate risks with plugins is to work with certified plugins only. I know this will give an addiional burden but at the end of the day it will give ensurance to both LT and the end-user that a particular plugin is suitable and compatible. Certified plugins should be listed (downloadable) from a managed site, this will make it easy to find them and may give the oppertunity to distinguish between plugins and dockers, read: give preferential advice. I understand that all focus is now on Docker and VM, but I believe there is still place and reason to have plugins. Not all plugins require third party software. The statement highly discourage doesn't sound like an invitation to continue on plugins, while they are still very useful. Knowing how much time and effort I've put in developping plugins (and the plugin manager), your announcement is 'bitter sweet'. Your work is an exception to the rule for the most part because your work falls in the category of webgui enhancements. Having certified plugins is something we have talked about doing and both python and Perl are examples of packages that could fall into that category. Sure, but the statement given is rather black and white, and people may interprete the message as "never use plugins because they are unsafe and pose problems". A little nuance would do. Certification definitely will help the stability of your product in the long run, that may also be true for dockers !

One way to mitigate risks with plugins is to work with certified plugins only. I know this will give an addiional burden but at the end of the day it will give ensurance to both LT and the end-user that a particular plugin is suitable and compatible. Certified plugins should be listed (downloadable) from a managed site, this will make it easy to find them and may give the oppertunity to distinguish between plugins and dockers, read: give preferential advice. I understand that all focus is now on Docker and VM, but I believe there is still place and reason to have plugins. Not all plugins require third party software. The statement highly discourage doesn't sound like an invitation to continue on plugins, while they are still very useful. Knowing how much time and effort I've put in developping plugins (and the plugin manager), your announcement is 'bitter sweet'.

Very nicely done, thank you! A small suggestion for the PLG file, which allows the original Dynamix file to be restored upon uninstallation. Instead of removing the original file, just rename it, e.g. # Rename original Dynamix page if [[ ! -f /usr/local/emhttp/plugins/dynamix/OpenDevices.page- ]]; then mv -f /usr/local/emhttp/plugins/dynamix/OpenDevices.page /usr/local/emhttp/plugins/dynamix/OpenDevices.page- fi And in the remove section add the restoral, e.g. # Restore original Dynamix page mv -f /usr/local/emhttp/plugins/dynamix/OpenDevices.page- /usr/local/emhttp/plugins/dynamix/OpenDevices.page

It does not appear before this. Just an idea, I have page refresh turned off, have a Refresh button top right that I use. Is it possible the lack of the auto refresh is bypassing the notification system? I think you may be on to it Rob. I applied the IT Crowd solution method ("have you tried turning it off and back on"). Tured it off, APPLY, turn it back on, APPLY... started getting them again. Maybe the initialization code need a look see? (it was on in 14b, 15 didn't pick up that it was on?) I have a look into this, thanks for the feedback.

Just double checking, what setting do you have for the "Array status notification:" dropbox on the 'Notifications Settings' page? Mine is set to "Send once a day". same as it was pre-15, 4 times a day Can you re-apply the "Notification settings" AND "SMTP settings". See if that makes a difference ?

Sure they're not getting caught in your SPAM filters? A simple verification is to set notifications to your browser too next to the email and see if these arrive.

Which destination(s) do you use for these notifications, browser, email, custom or a combination ?

Array active/inactive notifcations have been taken out. I don't even get health notices any more.... Array health notifications is selectable from the notifications setup page. You can choose a frequency and how notiifications are sent.

Array active/inactive notifcations have been taken out.

I find turning the screen off is the easiest way of doing that. My solution is ... no screen at all

No, it's UnRAID. We've discussed this before. Happened first with 14b. Still happens with 15. It's an easy fix, you just have to run "sensors-detect" from the local console or ssh, and then modprobe the resulting driver in the go file. See: http://lime-technology.com/forum/index.php?topic=39244.0 By adding the correct driver there will be sensors available, that is true and it is indeed the 'best' solution. It is also simple to surpress the error message in the first place.

I'm not so certain of that. I think it might come from the Dashboard "sensors" exec. I can't replicate this because my board always have the ACPI sensor, but I'm pretty sure about it. Maybe you can redirect the stderr to /dev/null. That might be a reason, I will redirect the error messages, thanks.

The "No sensors found" must come from something else installed besides unRAID itself. Check if you have any remains on your flash (folders: /extra, /plugins, /config/plugins, /custom, /packages). Also check the content of your go file

Download button for device SMART data in webGui http://lime-technology.com/forum/index.php?topic=38415.0 Bonniel said that he added this feature. Is it in the latest beta? Was it missed? Version B15 has only the attributes download for a disk, it was already requested before to get a complete report instead. This will be available in the next release.

Great, when can I expect unRAID in the Dutch version When, my Netherland brother, you lot finally manage to create a pure black Tulip. It's on the way, 2018 I believe ... You mean Today. No no, I mean soon

I like to put this in a bit wider discussion, inevitably at some point some package is required (though admittedly with Dockers this is less likely going to happen). We have learned from v5 that it isn't a good idea to let plugins install themselves other packages, different package versions and conflicts are the result. Thinking out loud - one approach maybe a central repository which can be used by plugins to get/install the required package(s), as opposed to a master plugin getting the packages instead. Or a combination of both - a master plugin retrieving packages from a central repository. The crux here is - who is going to maintain all of this and make sure that things stay up to date and complete ? Something outdated or incomplete, soon is doomed to be ignored and people follow their own road, that will be history repeating itself as seen with v5. Maybe I am a bit too skeptical here and the situation isn't that bad, at this point in time Dockers still need to prove they are better/easer/faster to setup and use than traditional plugins, which I hope will happen, but until then people will continue using plugins (these are still actively developped) and only switch when benefits are clear to everyone.

Great, when can I expect unRAID in the Dutch version When, my Netherland brother, you lot finally manage to create a pure black Tulip. It's on the way, 2018 I believe ...

Great, when can I expect unRAID in the Dutch version when they win the world cup. Well, 2018 it is then (gives me some time to write that plugin)