zoggy

And the scope creep continues you'd have to agree that updating a core package is a bit different than asking for a whole feature to be added. but im probably just feeding the troll here.

Tom, I see that we have php included in the core of unraid. testtower:/boot/unmenu# php -v PHP 5.2.13 (cli) (built: Mar 27 2012 14:28:43) This version is pretty damn old, 25 Feb 2010.. 5.2.x isn't even supported anymore (end of life was 6 Jan 2011). Any chance of getting it updated before 5.0 goes final? Notable changes on versions, note that we prob should just stick to 5.3.x to eliminate the need of having to do worry about anything getting broken (as 5.4+ would make me think there might be some code that needs updating since some things were removed -- for the sake of security) 5.3.X Namespace support; late static bindings, Jump label (limited goto), Native closures, Native PHP archives (phar), garbage collection for circular references, improved Windows support, sqlite3, mysqlnd as a replacement for libmysql as underlying library for the extensions that work with MySQL, fileinfo as a replacement for mime_magic for better MIME support, the Internationalization extension, and deprecation of ereg extension. 5.4.X Trait Support, short array syntax support. Removed items: register_globals, safe_mode, allow_call_time_pass_reference, session_register(), session_unregister() and session_is_registered(). Built-in web server*. Several improvements to existing features, performance and reduced memory requirements. * The CLI SAPI web server is designed for developmental purposes only, and should not be used in production. 5.5.X Generators, Zend Optimizer+ Latest 5.3.x is 5.3.27 from July 11th 2013. Change Log: http://www.php.net/ChangeLog-5.php#5.3.27 I know how much you wanna stay with official 13.x versions, so here you go: http://mirrors.slackware.com/slackware/slackware-13.37/slackware/n/php-5.3.6-i486-6.txz http://mirrors.slackware.com/slackware/slackware-13.37/patches/packages/php-5.3.27-i486-1_slack13.37.txz

Joe, small typo in the Perl package, 'cownload' should be 'download will be': whats currently listed, can see it doesn't make too much sense. grammar. Joe, I noticed that under the list of drives in the array.. the boot drive always shows up twice.. is it suppose to? See image:

Joe, did you ever get around to trying the updated apcupsd 3.14.10 (it detects which shutdown script to use)? For more info see the post: http://lime-technology.com/forum/index.php?topic=27051.msg255301#msg255301

People have lives, and I'm sure that working on documentation eats up a bit of time. Patience people. Put the pitch forks down. We've waited this long. I'd rather wait a bit longer and get a solid release than a rushed one where issues are introduced.

it deletes it when its installed.. thus if you just remove the package from the plugins folder, on reboot the normal webgui will be there (as it wont be removed since the new webgui package isnt being installed)

playing devils advocate here, unraid appears to be the coding efforts of one person. this one person has limited resources and time.. so I'm sure there are bugs to be found. so do you blame yourself for buying into a product with this situation? what about the free license/trials?

how would boxcar handle packages that are just a set of bash commands? example: http://code.google.com/p/unraid-unmenu/source/browse/trunk/monthly-parity-unmenu-package.conf http://code.google.com/p/unraid-unmenu/source/browse/trunk/mail_status-unmenu-package.conf http://code.google.com/p/unraid-unmenu/source/browse/trunk/ds_store_cleanup-unmenu-package.conf

Why dont we just do what unmenu does for packages? It seems to work well enough?

on a side note, For discovery purposes, the layout and presentation of 'plugins' like this page would work well for unraid: https://addons.heroku.com/ Show the top apps in whatever section.. based off downloads/installs. RSS feed of updates: https://addons.heroku.com/changelog So with that site in mind, here is how I'd in-vision it for unraid. so if one went to: http://addons.lime-technology.com It would show that page.. allow people that dont have unraid installed to see whats available. Then clicking on the addon would take you to the addon page.. http://addons.lime-technology.com/addon_name_here Which would provide details like synopsis, changelog, etc.. link to forum post/homepage/etc.. A RSS feed of the addon updates would be found: http://addons.lime-technology.com/changelog Now all this works well and provides a centralized place to know where to look.. now what about those actually using Unraid that want to install said plugins? Two scenarios come to mind, installing via gui or cli. GUI (initial install): on the addon page, (loads the existing webpage, that way if updates are needed the user doesnt have to d/l locally to get the update) offer an configure+install button which takes you to a tab/page of things to configure.. upon submission it submits the form and builds a .conf file for said package. (kinda like how unmenu does it). CLI (install on startup/manually): offer up sample .conf that the user would have to copy and update with their values Then the actual install process is just a wrapper to do pre-install steps, install the package + conf file for settings + post install steps.

they key is to get it out of the CLI and into the webGUI though! "New Disk, would you like to preclear it?" "Y/N" what about when the gui stops working? or if you rather just do it from a command line? i dont think we should lock someone into one environment (CLI or GUI) but give the user the choice.

maybe tom should do a poll of the top plugins to see what everyone has installed.. and then just include the top few to make everyone happy with a clean install / catch up to the other solutions? obviously testing needs to be done so that we dont introduce issue by including anything.. and there is an argument that can be said that tom should just focus on the core of unraid. With that all said, there is then some things to overcome. Something as simple as 'ups support' has been a hit and miss over the years if you look at the SF/Unmenu plugin. I've been running apcupsd-3.14.10-unmenu-package now for just over a month now without any problems. Now to properly do apcupsd you need to have mail installed (otherwise the notifications are a little pointless?) and then also you need the shutdown script (otherwise your system may not shutdown correctly -- a whole other battle to deal with). Thus its not just clear cut. Additionally, on the unmenu package we do a slight 'fix' - hack in delay on restart service (prevent the log rotation process from killing the daemon because the pid wasnt removed quick enough). This was the problem that plagued people from running 3.14.10 in the past. Then installing a plugin that requires configuration introduces more issues for Tom as he needs to provide a way to configure it? Something like the pre-clear script would be a welcome inclusion as it doesn't really require any config. Just needs to be there in case someone wants to use it.

+1 SSH should be available out of the box, honestly. some may not want ssh enabled to their box for security reasons?

doesnt just copying to the drive's mount directly bypass the cache? i thought the cacher works off things being written to the 'share' itself. instead of copying to \\server\TV you'd do \\server\disk#\TV

so back to what i've brought up before. The whole plugin thing involves multiple problems that need to be solved. Personally I do not think this is something that should be rushed.. or hold back 5.0. Especially this close to the finish line. With that said, there needs to be a dialog going from the community on what they want/expect/need. Especially when there are so many smart people willing to donate their time to make something better. Tom knows whats included with unraid and what he feels is worthy of including going forward. There are several apps that could be included with unraid by default that would make things a little easier going forward, however this then starts to add some bloat to the install - which some people may not appreciate / have the resources for. Python? Ruby? PHP? Perl? then SVN? GIT? BZR? CVS? etc.. The foundation is important and the choices we make should be sensible. What architecture should the plugin manager support? Should we only show the bleeding edge, or maintain the last 2 versions + beta/dev, that way we give options if one isnt working well.. fallback support? The package manager in slackware is not great for automation / unraid's purposes. I suggested using something like slapt-get that is a wrapper ontop of the slackware package manager (uses those calls) but extends it slightly to give it more 'apt' like feel. This is only one piece of the puzzle, and trying to figure out the tools to put the puzzle together is another battle in it self. It doesn't make sense to use bazaar if everything else uses git.. but services like launchpad offers translation support while github doesnt.. (I personally dislike bzr compare to git, but translations is one of github's weak points.. why with Sabnzbd we have a launchpad repo for translations and then everything else is on github) PHP allows one to write quick code.. but due to the lack of enforcing good coding habits.. its also very easy to write sloppy code. Perl allows for much more efficient code but there is a bit more of a learning curve.. Python works well and tends to enforce better habits, however it does have its own pitfalls with unicode strings.. Ruby can do some wonderful things but coding in it is not for everyone.. since its the new kid on block there also isnt the user base that the other languages have in comparison (prepare the torches).. Sticking to shell scripting seems to make sense but there are a bit of extra work involved as you can only do so much in a script (you can do some amazing things in a script.. but it takes that much more code compared to a 'real' language)... How does other NAS solutions handle their plugins? Synology, QNAP, Drobo, ReadyNAS, WHS, FreeNAS ?

so seems like this whole webgui dev isnt taking off like one would hope.. maybe post 5.0?

"Registering" means that there is a central list that the installer can pull from. This is the glue that creates a unified system. Anyone can register an addon. There is no peer review for this part. This is how rubygems and npm works--not a new concept. There's no "verification" here, and is probably not needed. Addons source should be open source on Github or other so the source can be reviewed by anyone. We could even introduce a "verification" or "official addon" system if need be to help bubble up the best ones. Addons should be hosted on their own repo. Git preferred. SVN is probably possible. Addons should provide their own licenses. They are not the responsibility of Lime Technology. the problem that i've seen with this approach is when people beat the actual authors to the punch.. and for example lets say they register 'xbmc' and that's not really the right one.. or ever worse.. a malicious one.. people then could quite easily install something they think is trust worthy but have ill consequences. anyways having some sort of moderation is a solution for that.. but thats more overhead than i'm sure tom or anyone wants...

mine shows the correct thing in the new webgui "Sat Aug 10 02:59:09 2013 CDT". where do you see the wrong time being shown at? (you using SF? unmenu? stock ui? new webgui?)

I personally dont like the install 'whatever' version it finds approach. For some things that may work okay.. but for most of us nerds.. we want a specific version or better... and with regards to certain apps they need a specific version or better.. for example Sickbeard/Sabnzbd need python 2.5+, python 3.x doesnt work. But then there are forks of sickbeard that need python 2.6+.. Anyways, slapt-get has a dependency model that closely follows how nodejs works.. PACKAGE NAME: man-1.5l-i386-1.tgz PACKAGE MIRROR: http://www.slackware.at/data/slackware-9.1/ PACKAGE LOCATION: ./slackware/ap PACKAGE SIZE (compressed): 166 K PACKAGE SIZE (uncompressed): 390 K PACKAGE REQUIRED: groff >= 1.56-noarch-1,man-pages | man-pages-de PACKAGE CONFLICTS: PACKAGE SUGGESTS: spksrc (synology community's package thing) have an interesting approach, they have a package dependency and what packages this is a dependency: example: https://github.com/SynoCommunity/spksrc/blob/develop/spk/git-server/Makefile the package needs 'git' installed and newer than 1.8.2. then listed is all the packages that need this to work.. (dropbear, mktemp, busybox) DEPENDS = cross/dropbear cross/mktemp cross/busybox SPK_DEPENDS = "git>1.8.2" this approach can get pretty messy and requires constant updating.. the dependency thing is going to be a pain no matter what. I thought about coming up with my own dependency builder.. so lets take sickbeard for example (it needs Python 2.5+ and Cheetah 2.1.0+). sickbeard would list 'cheetah' as a dependency.. cheetah is a python plugin.. it would list python as a dependency.. thus python gets installed.. then cheetah.. then sickbeard. everyone is happy and the correct order of install is maintained. so what the plugin manager would need to do is take the list of all its packages.. look at all its dependencies and expand those out to get the full list of all the dependencies.. and flag any known conflicting things like two versions of the same lib.. how to resolve the dependency concern is going to be another big debate i'm sure. but honestly this whole mess 'shouldnt' happen too much as people should not be installing everything in the world to make it a normal linux distro.. and the actual conflicts probably could be resolved pretty easily by just agreeing on a common subset.. or handling them on a case by case bases. some food for thought, In unmenu, there are various package types created over the years... there are some packages that install the dependencies it needs on its own.. so package x will install x,y,z. This approach works well for one package. But if each package did this.. there can be conflicts/issues/adds extra code to test and catch for things. This causes the package to be larger, harder to maintain across the board as the package dependencies are buried within the package. Over time Joe tried to move towards a 1 item per package rule.. this results in quite a few extra one off packages (while small) clutters the plugin lists. So for example there is one for python, one for python-cheetah, etc. Then there is a variant of this where the Perl package has an option in it to install a CPAN plugin.. instead of a separate package for the cpan module.

Tom, is there a reason why you recommend using slackware 13.1 over newer packages (I've had no problems installing newer packages myself)? Released: Wed May 19 04:40:19 UTC 2010 From the slackware 13.1 repo: [pre]python-2.6.4-i486-1.txz 06-Dec-2009 03:21 11M openssl-0.9.8n-i486-1.txz 30-Mar-2010 00:34 2.2M php-5.2.13-i486-2.txz 29-Mar-2010 01:45 3.2M[/pre] From the slackware-current repo: [pre]python-2.7.5-i486-1.txz 29-May-2013 08:29 11M openssl-1.0.1e-i486-1.txz 12-Feb-2013 00:58 2.8M php-5.4.17-i486-1.txz 16-Jul-2013 05:52 6.9M[/pre]

i think the plugin discussion is getting muddled with the concept of a plugin manager and a package repo. first thing we should do is focus on a plugin manager (installer) part where we can install local or remote packages (via url). the method for limiting where packages can be installed from can come later. if you want to take it in house.. or have a package list thats moderated.. or whatever. about the plugin/package installer.. the main thing that comes into play is something that is reliable.. can deal with multiple mirrors? retry if there are network issues? handle dependencies for other packages/requirements? rollback? logging? Support for http, ftp, rsync, and local filesystems? what foundation does unraid have already that can/should be use.. can we leverage something built into the os already? do we code something that uses python? ruby? bash? I personally don't know ruby so I would lean towards bash (unmenu's approach).. or python (but python isnt included.. and if we include it we do 2.x or 3.x.. I'd say 2.6.x and then we could use libs to do a lot of the grunt work, ex: Requests - http://docs.python-requests.org/en/latest/ ) Looking into slackware's package management options: A simple tgz package system combines the standard tar and gzip. Used by Slackware Linux and its closer derivates, there are a few higher-level tools that use the same tgz packaging format, including: slapt-get, slackpkg, zendo, netpkg, and swaret. The two that caught my eye are: http://en.wikipedia.org/wiki/Slapt-get -- slapt-get builds functionality on top of the native Slackware package tools (installpkg, upgradepkg and removepkg) enabling package query, remote fetching, system updates, integrated changelog information, and many optional advanced features such as dependency resolution, package conflicts, suggestions, checksum and public key verification, and transfer resumption. -- slapt-get uses the libcurl cURL library for transport. libcurl provides support for ftp, ftps, http, https, file:// and other resource types along with transfer resume for incomplete downloads. slapt-get also uses the GNU Privacy Guard library to validate signatures. -- slapt-get works with official Slackware mirrors and third party package repositories such as http://www.linuxpackages.net and http://www.slacky.eu/. slapt-get looks for support files, PACKAGES.TXT and CHECKSUMS.md5, in the repository for package information. -- supports multiple package sources (including linuxpackages.net) with the ability to assign priorities to each source. -- i18n support via GNU gettext with 26 language translations http://en.wikipedia.org/wiki/Slackpkg -- slackpkg is an automated package management tool written for Slackware as a shell script, like Swaret. However, Slackpkg does not resolve dependencies between packages. As you can see.. slapt-get is looking better and better. So if we just created a shell wrapper that uses slapt-get we may be golden? Looks like some people have already tried slapt-get out with unraid: http://lime-technology.com/forum/index.php?topic=28140.15 Then also from the slapt-get guys, cpan2tgz is a utility to create Slackware packages from CPAN Perl module distributions. I know there are a few people that may enjoy that. Was curious about the dependency support in slapt-get, on their FAQ I see: http://software.jaos.org/git/slapt-get/plain/FAQ.html#slgFAQ10 So looks like we would have to create a PACKAGES.TXT to add the dependency support.. http://software.jaos.org/git/slapt-get/plain/FAQ.html#slgFAQ17 some notes why dependency support isnt built into the default package manager: http://docs.slackware.com/slackware:faq#why_doesn_t_slackware_s_package_manager_do_dependency_handling

note for ant, when testing responsive design you can use: http://responsive.is/ alright, I'm off to work. I'll check back on this thread tomorrow.

the new ui in ie6 or 7.. somewhat useable but some useability issues for sure (lack of png support/float issues/unsupported css used). not that we should really support it.. since WinXP users can run IE8. Win7 users would be running IE9-10. But just in case you were curious what it looks like:

@husky:/boot/config/plugins/webGui# cat webGui.* | grep devices devices="0" devices="0" however its still showing listing unassigned devices...

most mobile browsers nowdays are more than capable of displaying a webpage correctly.. there doesnt appear to be any non friendly stuff used.. (like dropdown menus on hover). so your mobile device should be fine. you may just have to zoom in to have a decent touch target... but yes one could easily add css3's media queries to make the design responsive for the device being used (tablet/mobile/desktop). this could have been done as well with the previous stock ui..