nicinabox

Replied to your post there. In short, glibc is probably the culprit. Boxcar 0.3.0 gets this wrong I think. It has the version hard coded (2.11.1), and may be incorrect for the system you're installing on. Boxcar at this point is out of date with boiler and trolley and desperately needs an update. YMMV.

Your error is with ld-2.11.1.so. ld.so is part of the C library, which is typically glibc. glibc is one of the few packages that you must use from your slackware version. You WILL get segfaults if you have version mismatches.

Lowercase "y". Anything else will fail. See code: https://github.com/nicinabox/boxcar/blob/gh-pages/install#L37

Stripe will do you better.

Totally understandable. Releasing free software takes a ton of time and effort (and I'm sure you're short on both of those fronts). Are you planning on licensing these mockups or code so others can make derivatives?

Sorry, no. The web has progressed a lot in 15 years. Tables are for tabular data. It isn't a semantic layout element. The spec clearly defines this. It has nothing to do with performance, load, or concurrency.

Actually that information is a combination of the disk model identifier and serial number as obtained by SMART. It does make some sense! Though you are right when saying it isn't immediately obvious in what it means... (makes me wonder if I should change that too) Some of the unMenu screens display model and serial separately. When it comes time to actually pull a drive the serial is the most important. In fact all my drives have the serial on a manufacturer's sticker on the end where it is easily visible without removing any drive from the drive cage in the case. Kode, this is important. Design Model/Serial for real use cases That's the information provided by disks.ini, how does it look in boxcar? I would need some way to reliably store the information because I don't want to be doing smart lookups everytime you look at the page, could I not just explode by "_" and use [0] for model and end() for serial? Boxcar gets it direct from SMART: https://github.com/nicinabox/boxcar/blob/master/lib/boxcar/api/smart.rb#L16. You could memoize and store it in memory to prevent subsequent SMART lookups. SMART can be slow on some disks, so you'll want to use async when possible. Splitting on the underscore may or may not be reliable. Seems like it would work from this sample, but who knows in reality. There are some sample files in the repo I use for testing. You are, of course, welcome to them.

Actually that information is a combination of the disk model identifier and serial number as obtained by SMART. It does make some sense! Though you are right when saying it isn't immediately obvious in what it means... (makes me wonder if I should change that too) Some of the unMenu screens display model and serial separately. When it comes time to actually pull a drive the serial is the most important. In fact all my drives have the serial on a manufacturer's sticker on the end where it is easily visible without removing any drive from the drive cage in the case. Kode, this is important. Design Model/Serial for real use cases

+1 Also this disk information: "ST3000DM001-1CH166_W1F28XEV" is rather useless. It's impossible to look at and make sense of. You can get better, more useful data from SMART. (Boxcar shows the Model and Serial Number separately, check that out)

Looks better than I thought. I'm not convinced on the red/green to represent the drive type though. It looks more like the state and something is wrong on red. Another thing you might consider: the skeumorphic drive icons are really gaudy and unnecessary. I think you could use that space better.

FWIW I really don't give a damn about brand awareness. I'd be using this to manage my stack of drives, not to be inundated with more corporate branding. I'd much prefer sticking to just the vendor name. No logo.

Are you sure transcoding is your bottleneck?

I don't believe it is. H5BP, but not Bootstrap. Custom columns? I don't recognize it.

You should also strongly consider making this responsive. Many people use mobile devices to access it away from their computer. According to the survey, it's one of the the things that people almost universally do or want to do.

+1 and more guides coming (mostly already written and prepped for next release). Kode is also working on a GUI that integrates addons directly for a 1-click install

I think modifying the go file is considered a bad practice. The "correct" way to do it is on the startup or disks mounted event.

Fun explanation of the unix file system. Worth a read, even for experienced users http://tuxradar.com/content/take-linux-filesystem-tour/

Any idea how to go about that? Excellent point. I had completely forgotten about non-code content.

Generally speaking, default copyright laws apply to unlicensed code. All rights to your source code are retained by you and no one else may reproduce, distribute, or create derivative works from your work. That's probably not what you want. Please, take a moment to license your work so others may benefit from your contributions. http://choosealicense.com/ Thanks

You're bumping up on yet another shortcoming with the current plugin system. Forum's are a Really Bad Way to manage code and support requests. It doesn't scale at all. It creates tons of extra work for the moderators and extra work for developers. Authors should... * version and tag their code * use a proper tool for support requests * write a proper readme * perhaps maintain a project specific wiki if necessary The goal should be that plugins become autonomous, self-maintained parts that work together and don't require TONS of overhead. Github is a really really fantastic tool that would help ENORMOUSLY with what people are doing. Influencer did a really good job of this on his UNplugged repo (issues, wiki). This is the right way to go about it.

Technically, it needs licensing. It's not actually open source as it stands today. It's no surprise there was a conflict considering how the original code has been rather mishandled.

This exactly. I'd much rather see Guides that are up to date and easy to maintain. This really feels like an area that Limetech should be responsible for, but ultimately the burden will fall on the community.

Part of the reason why this is a bad idea, and why many new UIs are popping up, is that the underlying code is rather poor. By web standards it's easily 15 years behind. It's built with tables for goodness sake. It's doesn't matter what "look" you give it, the underlying design is not worth building on just to change some colors. It actually needs new design paradigms that aren't possible given the existing markup structure.

Feel free to comb through responses of the survey I did: https://docs.google.com/spreadsheet/ccc?key=0AkDJ4boS7kWOdHI5R3o4cTVRWGlKZDlQYVB2Zkhna3c&usp=drive_web. There's some good stuff in there that could give you direction for real problems that need to be solved (making it pretty is nice, but making it useful and not error-prone is better).

Just a thought-- you might consider putting this code in a gist so it can be versioned easily. Forums aren't exactly great for code sharing.