August 15, 201312 yr Check it: http://boxcar-addons.herokuapp.com/addons That "addon" is simply a boxcar.json file with metadata. This addon doesn't actually do anything, so it's the minimum required: { "name": "Addon Test", "version": "0.1.0", "description": "For testing purposes only", "author": "aitch", "homepage": "https://github.com/nicinabox/boxcar-addon-test" } View at: https://github.com/nicinabox/boxcar-addon-test/blob/master/boxcar.json This addon was registered using the boxcar cli tool: boxcar addon:register dummy-addon git://github.com/nicinabox/boxcar-addon-test.git Naming is unique and on a first come, first served basis. Anyone can register an addon. This is the app that runs the Boxcar addon registry: https://github.com/nicinabox/boxcar-addons Installing an addon runs through a few steps but it's basically: git clone, makepkg, move to /boot/boxcar/addons, installpkg, remove source. In the future the Boxcar web app will pull from this app via API, so installs can be done via CLI or Web. That's all for now
August 15, 201312 yr so for your addon thing, the unraid box would need what installed? ruby, python, gcc (*and the related tools, make/ncurses/automake/libs), sqlite, git thats going to be a hard sell to Tom i would think
August 15, 201312 yr How much bigger will stock unraid be with these dependencies. I suggest we start with that as if its 4 times it will as you say be an impossible sell. A few random points. I had always imagined all addons would be binarys and not compiled on the fly. We will need arch specific since 64bit is on the road map The metadata needs to clarify the license and copyright. Users need to be able to make an informed choice without hunting though code The version number is tricky. I suggest you need two. One for the upstream and one for the package itself. Edit: I am not against any of this as by far the most detailed and thought out response so far but it on the face of it seems elegant to use at the expense of adding a considerable set of dependencies
August 15, 201312 yr Author so for your addon thing, the unraid box would need what installed? ruby, python, gcc (*and the related tools, make/ncurses/automake/libs), sqlite, git thats going to be a hard sell to Tom i would think Boxcar needs to be installed. Core dependencies are listed in the installer. These are libs that most distros have installed by default. Limetech and Tom aren't responsible for this. It is (so far apparently) a hard sell to the community for whatever reason.
August 15, 201312 yr It is (so far apparently) a hard sell to the community for whatever reason. Most of us "old" unRAID users don't much care about GUI. Most of the newer users coming in see the GUI and do a WTH and turn around. Tom does understand all this but he IS NOT a GUI guy, plain and simple. Us "older" members also do not like to add things to our server that may increase overhead, when something on the server may already exist that can do the job. PHP/Ruby/etc does not make much difference, but since PHP already exists we would prefer to use that since it is included. We tend to only add things if absolutely needed. Hell, unMenu is an awk web server for gods sake. Joe L. did a great job getting unMenu started and then it has evolved and matured over the years.
August 15, 201312 yr Author How much bigger will stock unraid be with these dependencies. I suggest we start with that as if its 4 times it will as you say be an impossible sell. Core dependencies are typically around a few megabytes installed. I had always imagined all addons would be binarys and not compiled on the fly. There probably no reason for addons to be a binary. Using the native Slackware pkgtool we can pack and install on the fly (they're not compiled). We will need arch specific since 64bit is on the road map Yep! I've got this in the back of my mind, but I'm not yet sure how to deal with it. The metadata needs to clarify the license and copyright. Users need to be able to make an informed choice without hunting though code Added. It's MIT. Not sure how that would influence user choice though. All addons should be open source. The version number is tricky. I suggest you need two. One for the upstream and one for the package itself. Upstream is simply a source. It doesn't get versioned per se. I recommend using tags to tag a specific commit for release. Master is almost always regarded as unstable/bleeding edge.
August 15, 201312 yr Author It is (so far apparently) a hard sell to the community for whatever reason. Most of us "old" unRAID users don't much care about GUI. Most of the newer users coming in see the GUI and do a WTH and turn around. In my opinion, I believe the the bar for entry can be lowered for new users. The web app is one of those things that sticks out as being 10 years old. Web tech has progressed a lot over time, but it's also a lot easier to do compared to linux development. When I first started with unraid I did do a WTH and turned around because I thought it was a scam. The amateur nature of the interface immediately made me regret me decision. I talked with other friends of mine who also thought it was a scam. That's baaad! I believe unraid is a great product, and I've recommended it to several others. Unfortunately the GUI is a major point of impact for new users. It needs to be turned up a few notches in the way of a professional product. GUI is what it is on the face, but underneath there's an entire architecture for system and addon management. That's not a small undertaking! Us "older" members also do not like to add things to our server that may increase overhead, when something on the server may already exist that can do the job. PHP/Ruby/etc does not make much difference, but since PHP already exists we would prefer to use that since it is included. We tend to only add things if absolutely needed. Hell, unMenu is an awk web server for gods sake. Joe L. did a great job getting unMenu started and then it has evolved and matured over the years. I hear you man. It kind of sounds like "Why do I need Chrome? I've got IE6 right here!" If we are to push the boundries here, things needs to evolve. I respect that folks don't want to increase overhead, and that's totally okay. For the rest of us, I believe there should be a higher performance, opt in product. I'm not pushing this as an official extension of unraid, simply a community addition in the same vein as SF and unMENU. Of course my goal is to create something professional and very easy to use.
August 15, 201312 yr "Tom does understand all this but he IS NOT a GUI guy, plain and simple", then find someone (or two) to do what you are unable to do.
August 15, 201312 yr "Tom does understand all this but he IS NOT a GUI guy, plain and simple", then find someone (or two) to do what you are unable to do. Tom#1 is and has. Tom #2 is marketing and speeding_ant has been help/working with Tom #1 to update the look of the stock webGUI.
August 16, 201312 yr Author "Tom does understand all this but he IS NOT a GUI guy, plain and simple", then find someone (or two) to do what you are unable to do. Tom#1 is and has. Tom #2 is marketing and speeding_ant has been help/working with Tom #1 to update the look of the stock webGUI. speeding_ant is going to be less involved with this now from what I understand.
August 16, 201312 yr Author @NAS Back to your point about binaries and not compiling on the machine... We could theoretically save a step by delivering a txz if we could pack the addon on the server rather than after delivery. I'm not sure if it's possible to create package that can be installed with installpkg if it wasn't made with makepkg. If this were possible and packages wouldn't be limited to Boxcar-only. This distribution mechanism doesn't care.
August 16, 201312 yr "Tom does understand all this but he IS NOT a GUI guy, plain and simple", then find someone (or two) to do what you are unable to do. Tom#1 is and has. Tom #2 is marketing and speeding_ant has been help/working with Tom #1 to update the look of the stock webGUI. speeding_ant is going to be less involved with this now from what I understand. That's quite a statement. Source? Sent from my Nexus 7 using Tapatalk 4
August 16, 201312 yr Author "Tom does understand all this but he IS NOT a GUI guy, plain and simple", then find someone (or two) to do what you are unable to do. Tom#1 is and has. Tom #2 is marketing and speeding_ant has been help/working with Tom #1 to update the look of the stock webGUI. speeding_ant is going to be less involved with this now from what I understand. That's quite a statement. Source? Sent from my Nexus 7 using Tapatalk 4 PM correspondence
August 23, 201312 yr Author @NAS Back to your point about binaries and not compiling on the machine... We could theoretically save a step by delivering a txz if we could pack the addon on the server rather than after delivery. I'm not sure if it's possible to create package that can be installed with installpkg if it wasn't made with makepkg. I GOT IT! I'm building this tgz on OSX with 2 directories: install/ and root/ install/ includes doinst.sh (postinstaller) and slack-desc (package description) On non-slackware machine: tar -cvzf testosx.tgz install root On unraid/slackware: # installpkg testosx.tgz Verifying package testosx.tgz. Installing package testosx.tgz: PACKAGE DESCRIPTION: # Test OSX # Tests creating packages on non slackware systems WARNING: Package has not been created with 'makepkg' Executing install script for testosx.tgz. Awww yeeeaaa post installer Package testosx.tgz installed. It gives a warning about not being created with makepkg, but seems to have no effect on the installation. This is good news. We can go 2 ways with this: 1. Create a worker on the server that builds packages and delivers the tgz for download, OR 2. Create a cross platform CLI tool for creating a release: $ boxcar build transmission (runs tar command and builds tgz with info from boxcar.json) $ boxcar push transmission (creates a new release on server and uploads tgz) tgz and txz are both compatible with pkgtools.
August 23, 201312 yr It is (so far apparently) a hard sell to the community for whatever reason. Most of us "old" unRAID users don't much care about GUI. Most of the newer users coming in see the GUI and do a WTH and turn around. Tom does understand all this but he IS NOT a GUI guy, plain and simple. Us "older" members also do not like to add things to our server that may increase overhead, when something on the server may already exist that can do the job. PHP/Ruby/etc does not make much difference, but since PHP already exists we would prefer to use that since it is included. We tend to only add things if absolutely needed. Hell, unMenu is an awk web server for gods sake. Joe L. did a great job getting unMenu started and then it has evolved and matured over the years. I always thought Linux was built on progression and innovation, not conservatism. I will never understand why linux got so big and could survive while its biggest userbase turns out to be a bunch of oldfashioned conservatives who dont want to change things and are scared of progress and usability. But then again, if you take a unix base and add some innovation and usability to it, you will get Apple and OSX
October 1, 201312 yr If Boxcar is stable and dependable, from the looks of it I would probably install it as an option for servers I build for people locally. I haven't installed it to take a good look yet, but it does look promising and I am very interested to try it out. I think part of what prostuff is trying to say is to many of us (me included) unraid is very much a "set and forget" system. I do very little management so I honestly don't care what the GUI looks like. What little management I do aside from adding a disk I usually do via telnet so the GUI doesn't come into play. So from that POV the increased overhead has no payoff. A nice looking fully functional GUI that we rarely use. Now from a new users POV they are spending a lot of time on the GUI setting things up, playing with settings and hell probably just logging in to see the disk stats just because they can. That and newer, younger members probably don't know the command line very well, so a complete GUI solution is more important. In the long run I don't think Tom particularly cares for and definitely doesn't support 90% of the plug-ins out there, so it doesn't hurt to have it out there as another option.
Archived
This topic is now archived and is closed to further replies.