October 3, 201411 yr I'd kind of assume that safe powerdown, handling of "Unformatted", TRIM support, and UPS Safe Shutdown Support were fairly core features for v6. You know what they say about assuming, right? That said, safe powerdown and handling of "unformatted" are definitely features we need to get right for 6.0. TRIM support is already in unRAID for SSD devices as a part of BTRFS. Need to confirm with Tom if there was anything else we needed to do on this (was surprised to not see this as a "green bulb" in the roadmap yet. UPS Safe Shutdown is not a required feature for 6.0. dlandon's plugin will provide a solution for the short term. That said, I'm NOT saying that won't be done for 6.0, just saying if we had to push it out for 6.1, we could and I don't think that's a big deal. From your statement, I guess that you are looking for RC within a few weeks? With final at the end of Oct? Already got bit in the butt once by talking about timelines. Won't make that mistake again ;-).
October 3, 201411 yr I think you guys are doing a great Job! I really like the communication that both you & Tom are providing in the forums! Looking forward to upcoming RC releases. JM
October 3, 201411 yr Can you confirm system notifications won't be making it into 6.0? If so I'll stop waiting and focus on 5 for now
October 3, 201411 yr You know what they say about assuming, right? That said, safe powerdown and handling of "unformatted" are definitely features we need to get right for 6.0. TRIM support is already in unRAID for SSD devices as a part of BTRFS. Need to confirm with Tom if there was anything else we needed to do on this (was surprised to not see this as a "green bulb" in the roadmap yet. UPS Safe Shutdown is not a required feature for 6.0. dlandon's plugin will provide a solution for the short term. That said, I'm NOT saying that won't be done for 6.0, just saying if we had to push it out for 6.1, we could and I don't think that's a big deal. Sounds good, though personally I'm looking forward to having notifications and shutdown under control so it can be more like a 'real' server. I'd like to stick a UPS on it for Christmas and having the ability to safely shutdown the unit on a power out would save me the hassle of this unit seeming to corrupt the flash drive on any kind of power event. From your statement, I guess that you are looking for RC within a few weeks? With final at the end of Oct? Already got bit in the butt once by talking about timelines. Won't make that mistake again ;-). Can't blame a man for trying
October 3, 201411 yr Sounds good, though personally I'm looking forward to having notifications and shutdown under control so it can be more like a 'real' server. I'd like to stick a UPS on it for Christmas and having the ability to safely shutdown the unit on a power out would save me the hassle of this unit seeming to corrupt the flash drive on any kind of power event. As am I! Keep in mind, the first priority is matching feature parity with 5, which as of recently, we have. That said, know that notifications and UPS shutdown are definitely on the roadmap, but we want to make sure we get them right and not just rush them in there. Can't blame a man for trying And I don't ;-)
October 3, 201411 yr I'd like to stick a UPS on it for Christmas and having the ability to safely shutdown the unit on a power out would save me the hassle of this unit seeming to corrupt the flash drive on any kind of power event. I know that some people are reticent about using 'unsupported' third-party plugins, but the development of apcupsd and powerdown is being handled really well by dlandon, with cooperation and support from Limetech. I've been using both of these since a time when they were only available as unmenu packages (probably still running unRAID v4.6). I experience an average of two power cuts a day and, believe me, running my unRAID server without these facilities would be untenable. These plugins are very well tested and exercised here - I can assure you that they work very well - so much so that I really don't see a great value in having them built in to unRAID. Responsiveness to issues is much better than I've received from APC (although APC do now tell me that they have discovered that the problem I'm experiencing is caused by a firmware fault, and that this will be fixed in the third replacement unit they are sending me).
October 3, 201411 yr A few suggestions for plgman: Can you add a prompt when removing a plugin to be sure the user wants to delete the plugin. Just clicking "remove" is destructive and the user should be asked to confirm the removal. The stale plugins seem to have the wrong version showing. i.e whan I updated to b10, the stale version showed as b10, not b9 (the one being replaced).
October 3, 201411 yr Jonp, is the memory >1BG use only an issue at boot time? Because I gotta say at rest my unRaid-Xen dom-0 is using 254MB even with cache-dir running. It shouldn't be an issue at boot time at all. The root ram FS is < 1GB at boot. That said, if you have ANY plugins added, that increases it and depending on which ones, it could be a substantial increase. Also, 254MB?! That's really really low. Are you sure?! Screenshot please? Used: 253 ... that is the important one right? I admit while I say I have cache-dirs running, it is only running against media and backup files not music which is where the real high number of files lies. Can you type this in the console? free -m Report back with the printout... root@Tower:~# free -m total used free shared buffers cached Mem: 1931 1882 48 0 301 1328 -/+ buffers/cache: 252 1679 Swap: 0 0 0
October 3, 201411 yr A few suggestions for plgman: Can you add a prompt when removing a plugin to be sure the user wants to delete the plugin. Just clicking "remove" is destructive and the user should be asked to confirm the removal. The stale plugins seem to have the wrong version showing. i.e whan I updated to b10, the stale version showed as b10, not b9 (the one being replaced). Totally reasonable request (on the plugin prompt to remove). We are aware of the bug with "stale" plugins. The other half is that the idea of "stale" is a little confusing in and of itself. We will address.
October 3, 201411 yr A few suggestions for plgman: Can you add a prompt when removing a plugin to be sure the user wants to delete the plugin. Just clicking "remove" is destructive and the user should be asked to confirm the removal. The stale plugins seem to have the wrong version showing. i.e whan I updated to b10, the stale version showed as b10, not b9 (the one being replaced). Totally reasonable request (on the plugin prompt to remove). We are aware of the bug with "stale" plugins. The other half is that the idea of "stale" is a little confusing in and of itself. We will address. Maybe "Updated" instead of "stale"?
October 3, 201411 yr A few suggestions for plgman: Can you add a prompt when removing a plugin to be sure the user wants to delete the plugin. Just clicking "remove" is destructive and the user should be asked to confirm the removal. The stale plugins seem to have the wrong version showing. i.e whan I updated to b10, the stale version showed as b10, not b9 (the one being replaced). Totally reasonable request (on the plugin prompt to remove). We are aware of the bug with "stale" plugins. The other half is that the idea of "stale" is a little confusing in and of itself. We will address. Maybe "Updated" instead of "stale"? Eh, I think it should be like upgrade PLG and downgrade PLG from other plugins. That said, tom may have an even better idea for this.
October 3, 201411 yr Totally reasonable request (on the plugin prompt to remove). We are aware of the bug with "stale" plugins. The other half is that the idea of "stale" is a little confusing in and of itself. We will address. Maybe "Updated" instead of "stale"? Errrrmmm ... "Superseded"?
October 3, 201411 yr Not wanting to get into the ever ending plug-in debate but... Why can't some third party plug-ins be approved by limetech? Core functionally doesn't have to be built in. Just has to be either there by default or easily installed and work seamlessly as if it was. May be a bad example but somewhat the way xbmc changed. The scrapers used to be built into the core making it difficult to make changes/updates without the whole package being updated. They moved the scrapers to plug-ins so they could be updated without having to update the package. Having core functions be plug-ins I feel isn't a totally bad idea. But I am also not looking at this from a technical aspect and if for some reason a plug-in can't act the same as a core built in function then just disregard this post. But the whole point being, is there any reason not to include the ups plug-in by default, therefore unraid can say they have initial support with updates and improvements being pushed out via plug-in updates. Like how beta 10a was pushed out Sent from my SM-N9005 using Tapatalk
October 3, 201411 yr Not wanting to get into the ever ending plug-in debate but... Why can't some third party plug-ins be approved by limetech? Because we didn't write the code for them and we don't maintain them. Here's the scenario: [*]User downloads a "LT Approved Plugin" [*]Everything is working great. [*]Plugin author updates plugin and now plugin breaks. [*]User says, "HEY LT! WHY DID YOU APPROVE THIS!?" [*]The "blame wars" ensue I don't think people care who writes the code so long as someone at LT approves the code for use officially. Doing that at a point of time is one thing, but doing that as consistently and fast as plugin authors update their work, that's another story altogether.
October 3, 201411 yr Not wanting to get into the ever ending plug-in debate but... Why can't some third party plug-ins be approved by limetech? Because we didn't write the code for them and we don't maintain them. Here's the scenario: [*]User downloads a "LT Approved Plugin" [*]Everything is working great. [*]Plugin author updates plugin and now plugin breaks. [*]User says, "HEY LT! WHY DID YOU APPROVE THIS!?" [*]The "blame wars" ensue I don't think people care who writes the code so long as someone at LT approves the code for use officially. Doing that at a point of time is one thing, but doing that as consistently and fast as plugin authors update their work, that's another story altogether. Kinda works the other way also. Plugin authors sometimes take the heat for shortcomings in unRAID that cause a plugin to fail/glitch. You need to give the plugin authors more credit than you are. We are all adults here. I have never seen any "blame wars" over plugins - everyone just chips in to solve the problem and find a solution. LT doesn't necessarily have to formally approve plugins, maybe just a recommendation or suggestion. "Plugin authors are responsible for their plugins, not LT." This is similar to someone wanting a recommendation on hardware known to be unRAID friendly. LT cannot be responsible for every permutation of hardware and disks a user will throw at a server and I've not seen anyone blame LT because a certain hardware combination won't work. There are a lot of very talented and hard working individuals building and supporting plugins without any compensation, except to contribute to the unRAID community. LT should tap into that resource and take advantage of it, not suggest that there will be "blame wars" when something goes wrong.
October 3, 201411 yr Why can't some third party plug-ins be approved by limetech? Core functionally doesn't have to be built in. Just has to be either there by default or easily installed and work seamlessly as if it was. This seems to be what is happening with dockerman. I see absolutely no reason that this shouldn't also work for other, very valuable and well tested, plugins such as apcupsd.
October 4, 201411 yr Guys, I think your taking my comment out of context. We do recommend plugins and containers to folks all the time and totally appreciate the hard work the talented community devs put in here. Also, let's not forget that the unRAID wiki and the forums show our support for plugins, but they are use at your own risk. I don't know why anyone would think this is an unreasonable statement.
October 4, 201411 yr Why can't some third party plug-ins be approved by limetech? Core functionally doesn't have to be built in. Just has to be either there by default or easily installed and work seamlessly as if it was. This seems to be what is happening with dockerman. I see absolutely no reason that this shouldn't also work for other, very valuable and well tested, plugins such as apcupsd. Dockerman was merged into mainline after much collaboration with gfjardim. Additional plugins may be merged into mainline build as well. Also, regarding "blame wars," that was a poor choice of words. The problem is that for all the posts on the forum, we at LT get lots of emails from customers that need support and plugins have sometimes made that more challenging for us at times. Bottom line, if I haven't made this clear enough through previous posts: the community developers here are awesome, and they make great addons for unRAID. In addition, have you seen my blog post about some apps that community devs have made? This will continue. So again, please look at the context of my response to the original post.
October 4, 201411 yr Jonp, I do think that the most common plugins should be vetted by Limetech in terms of compliance with shutdown event triggers and other functionality that is expected to be part of any plugin. Maybe call these unRAID Compliant plugins or something??
October 4, 201411 yr Jonp, I do think that the most common plugins should be vetted by Limetech in terms of compliance with shutdown event triggers and other functionality that is expected to be part of any plugin. Maybe call these unRAID Compliant plugins or something?? We're getting a little off-topic and this is worthy of it's own thread....but, I think this is more a community responsibility. "The proof of the pudding," so to speak.
October 4, 201411 yr Jonp, I do think that the most common plugins should be vetted by Limetech in terms of compliance with shutdown event triggers and other functionality that is expected to be part of any plugin. Maybe call these unRAID Compliant plugins or something?? Let's be fair, there are a handful of plugins that enhance the core NAS functionality and then there are a bunch of others that extend non-NAS specific functionality (e.g. media servers, etc.) Things like powerdown, ups, and cache dirs are all on the roadmap. It wouldn't make sense for us to rewrite all that work that the talented folks here in the community have already done but there are also good reasons we haven't merged those components into the mainline yet. Fair?
Archived
This topic is now archived and is closed to further replies.