nicinabox

What if they were halted automatically when you decided to shutdown. What if they started automatically when you booted up? Would that solve your problem? This is ridiculous. Someone needs to fix that crap. Agreed but the experiences with sab has pushed me further towards virtualisation as a model.... Software can be a hit and miss affair. I think we've identified that sab has some core problems that need to be addressed. Virtualization of that process is a hack to prevent it from crashing the host OS. It's fine if folks want to go that route, but it's indicative of a bigger problem. I'm not sure that anyone would recommend that you play around on your production box. I keep unraid VMs around for testing my software. It's a good idea to have multiple environments that you can test in.

I agree. I need to do a little research, but I'm pretty sure boiler could do this out of the box. It could get added to the package automatically when it's built, so devs don't have to worry about adding support for it.

What if they were halted automatically when you decided to shutdown. What if they started automatically when you booted up? Would that solve your problem? This is ridiculous. Someone needs to fix that crap.

FWIW this has been a very repeated mantra with no actual tests or benchmarks. Lots of scare quotes though. While there are no statistics or hard data I can point to, all one has to do is take a look at the forums. The number of support threads involving GUI crashes or dependency issues from users not running any plugins at all is virtually non-existent. Users running a large number of plugins, OTOH, there's untold numbers of threads. I do recall this. I believe many, if not all, of the issues were rooted in dependency conflicts. Someone requires openssl 1.0.1c for one thing, and 0.9.8r for another. There's not dependency resolution, and then you get all kinds of problems. Many of the plugins themselves are actually quite simple. They're written in high level languages and I think for many of them (if not all), the problems don't lie in the bash or python scripts, but in the dependency conflicts. +1 same situation here.

There are a lot more libs available out of the box now--awesome! I've noticed an odd problem: some packages seem to not have all their parts available on the system. Here you can see glibc includes `usr/include/string.h`, but it seems to be missing from the system. root@Tower:~# cat /var/log/packages/glibc-2.17-x86_64-7 | grep string.h usr/include/string.h usr/include/bits/string.h root@Tower:~# find / -name string.h root@Tower:~# Thoughts?

FWIW this has been a very repeated mantra with no actual tests or benchmarks. Lots of scare quotes though. Highly unscientific as it may be but on the same hardware i had nothing but problems (memory hogging causing unraid gui to crash) with sab running as a plugin on unraid which were alleviated to a vast extent by moving sab to a vm. after a while though i completely dumped sab and now use nzbget. These kinds of experiences are extremely useful. Is there any way we could compile real data about the issues (process/memory usage, installed packages, logs, etc)? Unfortunately, on it's own it's highly anecdotal and can lead to misdiagnosis. Find someone with two similar, or better still identical systems to do a side by side comparison. but sab is known to be a major memory hogger in of itself and would be my prime candidate for shifting to a vm if i were still using it. Forgive my ignorance here... How does a VM prevent a memory issue in a running process? Wouldn't you end up with the same problem in that environment? Won't the VM need to draw resources from the host system to accommodate ballooning processes? (not trolling here, I really would like some technical explanations) running a vm if you run into a memory issue, it will drag down the vm only.... And that would ultimately cause it to fail, right? So why isn't the problem being fixed in the application causing the problem?

FWIW this has been a very repeated mantra with no actual tests or benchmarks. Lots of scare quotes though. Highly unscientific as it may be but on the same hardware i had nothing but problems (memory hogging causing unraid gui to crash) with sab running as a plugin on unraid which were alleviated to a vast extent by moving sab to a vm. after a while though i completely dumped sab and now use nzbget. These kinds of experiences are extremely useful. Is there any way we could compile real data about the issues (process/memory usage, installed packages, logs, etc)? Unfortunately, on it's own it's highly anecdotal and can lead to misdiagnosis. Find someone with two similar, or better still identical systems to do a side by side comparison. but sab is known to be a major memory hogger in of itself and would be my prime candidate for shifting to a vm if i were still using it. Forgive my ignorance here... How does a VM prevent a memory issue in a running process? Wouldn't you end up with the same problem in that environment? Won't the VM need to draw resources from the host system to accommodate ballooning processes? (not trolling here, I really would like some technical explanations)

FWIW this has been a very repeated mantra with no actual tests or benchmarks. Lots of scare quotes though. Highly unscientific as it may be but on the same hardware i had nothing but problems (memory hogging causing unraid gui to crash) with sab running as a plugin on unraid which were alleviated to a vast extent by moving sab to a vm. after a while though i completely dumped sab and now use nzbget. These kinds of experiences are extremely useful. Is there any way we could compile real data about the issues (process/memory usage, installed packages, logs, etc)? Unfortunately, on it's own it's highly anecdotal and can lead to misdiagnosis.

In the past I've found glibc to be the culprit of cron segfaults.

FWIW this has been a very repeated mantra with no actual tests or benchmarks. Lots of scare quotes though.

Can someone explain the benefits of using a virtualized environment on a RAM disk?

It's probably worth pointing out that boiler and package-virtualization aren't mutually exclusive. Boiler is agnostic to what your package is and it provides a standard distribution mechanism while doing packaging on the host OS. You could in theory use the boiler registry to distribute packages designed for the virtualized environment. The registry is basically akin to a linux repo. Every package system needs some origin source from which to pull packages [1]. Boiler takes the core package and maps the files work for unRAID [2]. The same core package could be remapped for any other OS with a simple configuration, and there's still only 1 package to maintain. That cuts down on potential bugs and maintenance overhead that would be incurred by multiplying platforms and architectures. It's a similar to a build-once-run-anywhere approach. THEN AGAIN... maybe maintaining a separate repo for virtualized environments is the right way. Some of this just needs to have some prototypes built to see what really works. Does that make any sense at all? [1] I designed the registry to be maintainable by the community, without being burdensome. Anyone can add it to it without intervention. [2] unRAID has unique challenges with the RAMfs, so boiler maps stuff automatically to persist configurations, do updates, put bin's in your PATH, etc.

Take off your programmer hat, put on your marketing one. Stop talking / educating, asking for permission and provide a solution that users can use TODAY. Users do not care / need to know how a plugin works. Create a separate thread for every plugin that you have done and indicate in the title it works for unRAID 5.X and 6.X. (and keep adding the ones other than the few you have) That is how users and the plugin guys are going to know / see / use your program. How many people do think know how unmenu works, how it installs packages, that it's a awk? Get after it! I see we're going to have problems. 1. I did build a solution that works TODAY. It is natively rooted in the OS. 2. No one REALLY wants to spend their time scouring forum threads looking for a plugin that may or may not work. They do it because the are HAVE to. 3. Users do not truly care about the DIFFERENCE between 5.0 and 6.0. They just want their software to work and not lose their data. 4. UnMENU's slackware packages out outdated and incompatible with many plugins. And those are SLACKWARE packages. Not the same thing. Besides, UnMENU has a fundamental gatekeeper problem. 5. They way people think about plugins is because of the way the system was (not) designed. That doesn't prevent it from growing/changing/evolving. > Users do not care / need to know how a plugin works. No, they probably don't care about the technical underpinnings. They DO CARE that their experience isn't a shitty one.

What the plugins are isn't as important as how the system works. The plg system was not designed for how people want (or expect) to use it today. In order to move forward, we need to identify the core problems with the system and work towards a solution. Like I said before, the problems are extensive and multifaceted. We need standards, infrastructure, and tooling. Real people need to put their heads together and be empathetic towards the problem instead of aggressively pulling in different directions. You think virtualized plugins are viable? Great, build a distributable prototype and get feedback!

I think asking people which management option they would like would be something akin to "browser wars" on a smaller scale and you'd be hard pushed to find a general consensus. Agreed with the lack of XEN support in OSX being a bugbear, but i have a windoze instance that I use for XBMC that doubles as my XENSERVER remote admin rig. If there's one thing you can know for sure about the unraid community, it's that there will be no consensus. There's more than one viable solution, but design-by-committee never works out well for anyone. Lots of people have opinions about how x should be done, but very few are qualified opinions.

NoScript would cause it to fail I'm thinking.

I get a blank page when I go there. Only thing listed is "Herding unicorns..." Craaap. Might be a javascript error on the page? It fetches from http://boiler-plugins-list.herokuapp.com/ It works for me in Chrome and Firefox; what browser are you guys using?

Just because I drive the Short Bus doesn't mean I rode on it when I was in school. That is what I meant by rewrite. Also, there isn't that many plugins. Why don't you do it yourself and put them in your git (fork the ones who have a git) so you can get everyone using boiler by "default"? There are a number of plugins already available for boiler.... actually just went over to the registry page and it's blank...huh Here? http://registry.getboiler.com/ There are 9 listed.

I understand that. The plugin guys still have to rewrite their plugins to use it. Not entirely. The converter will get it 95%, maybe more. All the plugin code, files, configs are compatible. It's really just putting it in a file structure, rather than a flat file. Yes

It's works and works quite well. The problem is... 1. unRAID / Slackware doesn't have a package manager. 2. unRAID uses a root ramfs. 3. Plugins as they are today download various packages / libraries (who knows which version you get) and many of those are 4+ years old. You cannot download 32-Bit Packages / Libraries for XBMC 10.0 from Ubuntu 8.04 repo and install it in 64-Bit version of Ubuntu 13.10 and think / believe it will work (it won't). There were WAY to many changes to shared libraries, packages and the underlying OS / file structure for it too. unRAID 5.0 is based on Slackware 13.1 (4+ Years old = Ubuntu 8.04) and all the various plugins install packages / libraries from 4+ years ago too. Even if everyone wanted 32-Bit packages for unRAID 6.0 (which almost all of us don't)... The plugin guys have redo them anyway so they can grab the Slackware 14.1 32-Bit packages / libraries. Might as well forget 32-Bit and have those guys focus 100% on 64-Bit only. Otherwise we now have 3 versions of each plugin. Slackware 13.1 (32-Bit), Slackware 14.1 (32-Bit) and Slackware 14.1 (64-Bit). If I was a plugin guy (who creates / maintains them for FREE)... I wouldn't want to maintain 3 versions. Now you pay me, then we can start talking but I am not posting it on the unRAID forum though. See my comment here about how trolley can do this automatically. No one should have to maintain more than 1 version of their package. Using boiler we can define dependencies by name and version, and let the system handle arch automatically.

I'm trying to upgrade my testing VM from 5.0.2 to 6.0-beta. I'm get this error on startup: VFS: Insert root floppy and press ENTER What am I doing wrong?

Completely agree. The two that come to mind instantly would be a VM manager and APCUPSD. I think it's unlikely that this will happen. Part of limetech's philosophy on the unRAID product is that the dist remains as light and small as possible. Fewer moving parts means more reliability. That said, folks should be able to tune their machine to their needs. Most folks wont have an APC and won't need that feature. But for those that do, being able to add that functionality from an "official" place would be a huge benefit.

I'd like to see someone make a proof-of-concept of that system. Boiler solves this by allowing you to specify deps by name and use a version constraint. Honestly, 6.0 would be a good time to deprecate the plg system. The shortcomings with plgs run so much deeper than "should we change the file ext to plg64".

That was fast. I'll test boiler tomorrow for real. The code definitely works, but I suspect a dependency problem now that I think about it. I'll get the package api updated for 64bit too. Tom: a big thank you for keeping these releases coming. I deeply appreciate your work; I know how thankless it can be.

So are you saying boiler will work fine on 6.0 (I.e. 64bit) as is or do you need to make some changes to it? Sent from my Nexus 4 using Tapatalk That is correct. In fact, it has already been tested on 64 bit Cool. So from what I read it sounds like this means the packages in boiler/trolley will work fine as is? Sent from my Nexus 4 using Tapatalk That's the idea. Obviously it should be tested on a real machine, but my dev machine and the CI server are both 64-bit. If tests pass there it's a pretty good bet it'll "just work" on unRAID. If there are any issues I'll have a fix out pretty quick