Ok, maybe something more like unRAID-minimal and unRAID-full.  I think you could go up to three versions, -minimal, -medium, and -max.  Basically the -minimal would have just the bare necessities to run unRAID, heck you can even leave out such essentials as gzip, installpkg, just whatever.  It'd probably be nice to be able to still telnet in though.  -medium could have some of the basics that people keep asking for.  Gotta have gzip, installpkg, a lot of the different libraries, etc.  Basically this would be good enough to download and run most packages anyone would want.  -max would have it all.  Maybe you don't have to go so far as to have the kernel sources installed, but definitely the kernel headers, gcc, make, basically you can download source files and be able to compile without much fuss.

 

I know a lot of people are wanting stuff added back in, but a lot of other people are running on systems with the minimum requirements.  If you split it into at least two versions, then that'd make most everyone happy.  Three versions probably is a little overkill, but I'm sure some would appreciate it (and if it's easy to compile programs, maybe you can get more users to submit their own rolled-up packages).  Now everyone with the minimum specs can keep using unRAID without worrying that they'll have to upgrade soon, and those who are using 4GB of RAM can go all out.

Considering the time involved in creating 3 different packages and the man power available.

I don't know if it's necessary to go that route.

 

I would much rather see the manpower involved in features on the laundry list.

 

So far, the environment has what is needed to function.

To install new packages is a fairly easy process.

 

However, I would suggest a change log for versions so we know what is removed from the distribution so we can compensate.

 

Also having basic and 3rd parry packages available here would make it easier for the community to access and install.

 

 

 

 

 

 

It shouldn't be that hard, plus like I said two would be more than sufficient.  Tom keeps talking about all the stuff that he had to take out, how about just leave one root filesystem alone, and keep trying to take stuff out of the other?  In theory you'd only need to really test out the minimal distro, as long as everything works as it should there it should work in the maxed out distro (no worrying about taking out something that was crucial).

 

Personally, I'm doing ok with having to install a dozen or so packages when I need them, just figured it might help out others.

It's not hard, but I disagree in consideration of our developers time.

From what I gather, there are not allot of people behind the scene developing the core unraid.

Considering how much time and support will go into handling two distributions of the same base, I don't agree that the effort and time spent is worth sacrificing the development of new features.

 

There's a whole ongoing support effort behind the scene that will continue and grow

 

There are enough seasoned veterans on the forum that can assist with additional user level featues

 

I think by developing a drop in architecture of directories for packages and scripts would be better.

This allows a standard way of adding packages without the support issues of modifying the go script.

 

Perhaps it would be an interesting show of hands to put it to a vote with a POLL.

 

Developers time

Multiple distros vs New Features

 

 

Gotta agree with WeeboTech - asking Tom to add add'l configuration management would result in less time for enhancements and more support calls.

 

Tom's basic model is to provide a "lean and mean" configuration, while providing the tools necessary to add add'l features (packages) to the configuration.  This seems to meet everyone's needs.  Occasionally, as Tom is moving to a new underlying OS version, some files are omitted from the distro.  This is part of the BETA testing cycle, and Tom adds them back in.

 

Having Tom try to decide what (non-unRAID) addons to include in different configurations woiuld be impossible.

 

The enhancement I'd really like to see is the ability to remove a disk from an unRAID array without losing parity.

We're talking maybe an extra ten minutes per release.  Do all the testing on the -minimal version, when it works then copy the changed files over to the -max version and run whatever script is used to package everything up.  I can argue that it would also save some time, since Tom won't have to go back and keep adding files that he took so long to strip out.  If your package doesn't run in the -minimum, then try it in the -max version instead.

 

But it's just a suggestion.  If it's easy to implement and others want it, then there you go.  If I'm way off base and it's too hard to implement, then no worries.  I only mentioned it because I saw more than one post where someone complained that an extra package needed extra files to work, and Tom said he'd add them back in.

josetann, I don't think you have any concept of what it takes to make an unRAID release.  It would not take "10 minutes."  QC requires vigorous testing by Tom.

 

One problem with a "bloated" version is that EVERYTHING has to live on the initramnfs (RAMdisk) and that takes away from your regular RAM.  Linux does not like running out of RAM.

 

I use what you might call a "bloated" version of unRAID, with Apache, NTP, utilities, instrumentation support, and several other packages.  To do so, they have to reside ON DISK and not on the RAMdisk.  Only the end user can do this, as Tom has no way of knowing what physical disks will be in the system... the only way he could possibly do it is to point to additional applications on the flash, and let users symlink them to a disk of they want.

 

The tools are there for any end user to compile their own kernel and do whatever they want with unRAID.

We're talking maybe an extra ten minutes per release.

 

We disagree here. In theory it may take only 10 minutes to put an image together, but practically it will take hours testing and rebooting to test it all out.

I would say it would take approximately 8-16 man hours to build an automated mechanism to support the two distros.

 

Thereafter we're talking many man hours of ongoing technical support managing two distos for the life of the product.

 

  I only mentioned it because I saw more than one post where someone complained that an extra package needed extra files to work, and Tom said he'd add them back in.

 

I saw this also, This is part of the beta cycle. It's like a bonsai tree where you prune and stimulate growth in different areas.

 

I still say Tom's time is better spent working on features that the seasoned veterans cannot do themselves.

I.E.

Like the suggested removing of a data drive without a full parity sync.

Multiple drives (raid0 or concat) for Parity.

NFS

and a laundry list of others.

 

These are things that we cannot all do ourselves because it requires modification of the emhttp and the whole unraid subsystem.

 

We can easily add packages with a few commands.

 

With all due respect, I've posted a poll, Let the customers decide.

http://lime-technology.com/forum/index.php?topic=1718.0

 

 

Although many times I've shown my position on that I'd like to see a more complete version of unRAID, I am with the majority here...

 

Tom needs to keep this clean. No "special" extras.

 

AS LONG AS THERE IS A NICE WAY TO ADD THOSE YOURSELF.

 

There is definitely a way already. What I am "for" is:

 

1) An even nicer way (packages and more "drop-in" folders is definitely a step forward).

 

2) Addition of simple scripts/packages that have already proven their usefulness (for the whole "unRAID public") ...for example:

 

- Email notifications.

- The performance boost trick (if it is a trick) ...I am not sure why it is "ignored" still.

 

I love that MC was included after such a sort time after I proposed it (seems that Tom found it useful himself hehehe).

 

I would also love many of the things in the laundry list.

 

That's about it.

 

You see josetann in another thread I request help on what to do for a torrent (and maybe even emule) client. I would never expect Tom do add such a thing in his build. I would of course love an easy way for me to do it though.

 

It is not (only) that something extra "complicates" the build and take 10 or X minutes to make the "Full Extras Version". It is something else you need to consider: He then has to suffer all of us asking for debugging THOSE EXTRA FEATURES TOO (that in the end are not HIS responsibility, yet, HE is going to suffer all that).

 

So, I am For unRAID as is (plus a few small proven tweaks), but I want Tom (until he build a real team by him) to concentrate on unRAID core.

 

 

I think that taking Tom's focus off of his core product is not a good idea.

 

Although I would love to see a full development version of unRaid, Tom's version of unRaid, as it sits today, works perfectly for its intended task. Anybody who is able to do development can install the packages they need and extend today's version.

 

I can see why Tom is keeping it simple.  Every change to add complexity, adds dramatically to the support issues.  It is difficult enough to keep ahead of hardware support needs.  Yes, most current hardware can be made to work, but "current today" is soon enough unavailable, and outdated, and it has been a huge enough effort to keep up with kernel upgrades for Tom.  To his credit, the continued migration to newer kernels has allowed mixed use of PATA and SATA, and now support of port multipliers. 

(version 1 of unRaid was IDE only...SATA support was not yet in Linux, hardware to run it not available/affordable)

 

For us developer geeks... we can modify our unRaid servers as we desire.  We can package cool improvements and added features.  We can add features we need and perhaps nobody else might ever consider.  That is the advantage of building on Slackware/Linux.

 

There are a few improvements that will help us geeks.  The addition of "hooks" on specific events, array start, array stop, etc, as discussed in another thread will allow our added packages to cleanly start and stop.  The addition of a simple method (click this button) to copy the current syslog to a file on the flash drive will assist newbees in getting the help they might need.    These are two examples... one for people with no command line expertise, the other for those with lots.

 

The Laundry List of desired improvements is where I think the focus should be.  From what I can see, the addition of NFS support is highly desired.  The addition of support for UPS power/management messaging is very important to many.  E-mail alerts if abnormal status still important to many.  With each comes the need for additional support and testing.

 

As a developer, we can easily install any of the power management packages, but there are thousands of UPS units out there,each with their own protocol.  It is a huge task to support them all.  Best bet is to allow installation of any of the UPS packages and supplying the hooks to allow it to manage an orderly shutdown.

 

The difficult part for many programs is the orderly shut-down of the array from other than the management console.  As I said before, a few "hooks" there might help.  An "api" interface to the "Stop" button on the management console would be very helpful.  A "thread-safe flag" or "semaphore" to report on array status and that could be safely monitored to know the array has stopped before powering down would help.

 

Rather than bloat up the unRaid release, I might suggest that Tom just make available for download the unmodified kernel source bundle he uses for each release.  Those of us who need to compile something special can then do so easily with the unRaid supplied config file.

The addition of a few hooks to coordinate startup/shutdown tasks/activities, and making the /proc/mdcmd interface thread-safe will make the rest of us happy.

 

Joe L.

We're talking maybe an extra ten minutes per release. 

I am reminded of the old adage -

 

"Nothing is impossible for the person that doesn't have to do it."

 

"nothing is impossi...." awesome !!!, ive never seen that before !!

Im fond of this

"other peoples time?, of that I have plenty", crudely translated from danish "andre menneskers tid har jeg masser af".

 

That was a sidetrack,sorry, anyway the development of Unraid should be focused on the basics, and I find the laundry list to be a good illustration of just that.

 

Yes, there are things that I like to have running, and for that I rely on 3'part. If problems then I blame my self, strip all, and are back to a working Unraid server.

Im cynical, so when people want something I ask what they are willing to pay. If they are sure of something I ask them how much they would bet. Money somehow is a good measurement of need and beliefs.

/Rene

 

 

 

Seeing that some want more in the unRAID distribution and others want to safeguard the developer's time, I guess we can all agree that unRAID should sit on top of standard Slackware. In particular, no development time would be spent deciding and testing what things can safely be taken away, and the beta cycle could focus on unRAID itself. Granted, the idea of running off a USB stick would probably have to go, but after the initial techno rush over the fact that it can be done, the USB constraint does seem to be an awfully limiting factor, in particular for a non-embedded product.

 

Or, are there compelling technical reasons for crippling Slackware?

I'm not sure that the need to boot off a USB drive is built into the unRaid product... If you are comfortable in linux, I'll bet you can boot off of just about anything, mount a file-system at /boot with the appropriate files, invoke unRaid's emhttp and it will probably work just fine.

 

The USB release with bzroot and bzimage just makes the product usable for 95% (or more) of Tom's customers who have no Linux knowledge.

The USB release with bzroot and bzimage just makes the product usable for 95% (or more) of Tom's customers who have no Linux knowledge.

 

I'd like to hear how you arrived at that figure ...

We're talking maybe an extra ten minutes per release.

 

We disagree here. In theory it may take only 10 minutes to put an image together, but practically it will take hours testing and rebooting to test it all out.

I would say it would take approximately 8-16 man hours to build an automated mechanism to support the two distros.

 

Thereafter we're talking many man hours of ongoing technical support managing two distos for the life of the product.

 

 

I don't think it would.  We're not talking about two radically different distros.  We're talking about the core version, plus a version that's not so stripped out.  Assuming there isn't a huge change (like changing to a newer version of slackware), it'd go something like this.  You have a regular bzroot directory with all the goodies left in.  You have another bzroot directory that's completely stripped down to the bare essentials.  You develop on the bare bzroot directory, that's the one you roll up and test out yourself.  When you're ready to make a release (whether it's a beta or the full release), simply do a cp -r from the bare bzroot directory to the non-stripped-down bzroot directory.  This way all the changes you made are incorporated into both, and all the extra libraries, kernel sources, etc. are still intact in the regular bzroot.  Make both directories into an image file, and release.  The only thing different between the "distros" would be the bzroot itself.  Now, the added time to run the cp command and the command to make an image out of the second bzroot directory should be less than ten minutes.  There may be some files that you don't want overwritten in the regular bzroot directory, so the time to copy those files into a safe directory (needed to be done once only) and then back in after the cp -r, that might add up to ten minutes.

 

Now, if Tom was to have to implement this right now, it might take a couple extra hours.  He'd need to make a complete copy of the current bzroot he uses.  Then he needs to add back in a lot of stuff he's taken out.  Since he's having to add stuff back here and there, one can argue it wouldn't really take that much longer.  Right now he has to read reports of missing libraries, then add it back in, see that something else was left out that someone wants, add that back in, etc.  Just do it once and be done with it.  Whenever someone complains of a missing library, you'd just ask them if they're running the -minimum or the -max version.  It will most likely be the -minimum version, so just tell them to try the -max.  Once Tom makes a big change and has to redo the whole bzroot, that's when it really doesn't take any extra time to do this.  Just do a basic install of Slackware, save that bzroot, make a copy, then hack the heck out of it, strip it to the bone.

 

Of course, this isn't the ideal solution.  I'm just trying to compromise between what a lot of people want, and Tom's business model.  Ideally we could just install this on a standard Slackware install.  Barring that, we could have an easy way to make permanent changes to the bzroot.  By that, I mean when a new release comes out we just copy over the files as instructed and that's that.  I don't mean extracting the bzroot each time, adding your stuff back in, and rolling it back up.

 

Off topic just a bit, but has someone actually tried porting this over to a regular Slackware install?  I haven't bothered as it's working good enough for me as-is, but if you could extract the filesystem to a regular drive, couldn't you point one of the scripts to just mount that drive instead of extracting bzroot to ram?  You can still boot from the usb key, of course you'd need it for the license file, all you'd really need to do is edit it to let you mount a regular hard drive partition as /.

 

Anyways, I need to reiterate that I'm not trying to take away any development time.  If I'm way off base and it's going to take an extra 12+ hours for Tom to do this each time he releases anything, then it's obviously not worth it.  If we're talking an extra 30 minutes to an hour for the whole development cycle (i.e. the entire 4.4 series), then I think it's worth considering.  And I must double-reiterate that it's not a feature I'm trying to demand he do just for me, I've already worked around the limitation.  Took me several hours to find everything I needed to install, but that was ok for me.

How about making it a Live CD, Ubuntu style: it can run as a Live CD forever, and you have a one-click option to install the system locally.

 

edit: actually, a Live CD will fit on a USB drive ...

aren't we carried off topic?

 

 

How about making it a Live CD, Ubuntu style: it can run as a Live CD forever, and you have a one-click option to install the system locally.

 

edit: actually, a Live CD will fit on a USB drive ...

 

Not a bad idea.  Of course it wouldn't be practical from an actual CD, it'd take forever to load plus it'd take up a 5.25" bay in your PC (and you'd still need the usb key for the current licensing scheme).  A usb key is much more practical.  But having an option to install it from the usb key to the hard drive would be great.  Then it'd just be a regular linux install.  It might take a while to develop this though, a poll would have to be made.

The USB release with bzroot and bzimage just makes the product usable for 95% (or more) of Tom's customers who have no Linux knowledge.

 

If it was made to run as a regular linux install, then it'd open a whole world of possibilities up.  I've read that one of the reasons NFS isn't supported yet is because of the fuse filesystem used (as a result of everything being stored in ram).  If that's no longer a problem, then we can install NFS support ourselves.  Want to run Tversity or some other windows programs to deal with your media?  Just install VMWare, load up Windows, and there you go.  Everything's done on one machine.  Want it to serve as your NAT server?  Sure thing (just make sure the data stored isn't sensitive information).  Use it as a regular desktop PC if you want (either with linux, or using Windows as a virtual machine).  Need something to control all your home automation stuff?  Not a problem.  Just build one overkill server to do it all.

 

Granted, unRAID as it is is helping me to consolidate several of my computers.  Where I would have to run three before, now I just run one (I had one Windows machine that had two drives shared, a linux server with important stuff on it in a RAID-1, and my asterisk server).  Now, I still need to have a Windows machine running all the time, so either I have my Mac run a virtual windows install all the time, or I leave my laptop on all the time (which I used to do, but now the wireless cuts out when the lid is closed part-way, it actually cuts out before the display does so no it's not an ACPI thing).  Things would just be easier if it ran on a regular linux install.

 

Now, maybe Tom doesn't want all the extra attention that would bring.  Sales would be great for a while, but the more people that have it and the more useful it is, the more likely someone will try to reverse-engineer it.  The raid driver is already gpl code, you just need a way to interact with it.  Eventually sales will slow down.  If he can anticipate this, he should be ok.  Kinda like Digium and Asterisk.  Sure, Asterisk can be installed for free, but if you want it to just work and have support, get a system from Digium.  So if people want to roll their own they'd do so.  If they want a nicely packaged system that works out of the box, with a polished gui and great support from the creator, then buy from Tom.  Plus, an added bonus of having so many more people using the product is that many more people will be contributing ideas, fixes, what-not.  Maybe a bug is found in the raid code and someone posts a patch.  That's something Tom didn't have to spend any time on, except the time to apply the patch (and make sure it works with his proprietary code).

simply do a cp -r from the bare bzroot directory to the non-stripped-down bzroot directory.

 

What your failing to see is the time involved ongoing, to supporting 2 distributions.

I'm talking about customer support, not the "10 minute" programming support.

 

There are going to be umpteen questions, the first always being which distribution.

 

Redhat has PLENTY of people to support all the variations of distros, does Tom?

 

Now someone mentioned using the base slackware install, and this seemed to be a better possibility.

 

If an unsupported package were introduced which installed the current slackware kernel without the standard md driver and with the new unRaid/MD driver (Plus the support programs).

 

Then there's a possibility..

 

Still I think it's time spent out of the context of unRaid as a product.

 

What really attracts me to unRaid is that

A) boots off a non hard drive device.

B) Loads root into Ram

C) Is designed specifically to be in ram and spin down drives on non use.

D) Maximizes use of hard drive space as units of spindles. A Protected JBOD.

E) Creates a consolidated tree view of your files through user shares.

 

This is a MAJOR factor for unRaid.

It's a fileserver/NAS product. Let's remember that.

 

It's not hard for veterans to recompile the kernel and slap it over a standard slackware distro.

Perhaps if people pooled together, then a package could be derived that others can use.

 

I'm still in the camp where the developer works on the issues and features we cannot do ourself.

Installing unRaid over a slackware distro on a hard drive (or a new ramdrive) can be done by a seasoned linux admin/programmer

 

From what I remember, there is a thread around that shows how to extract bzroot to the hard drive.

Add your packages to the directory, then repackage bzroot for placement onto your USB key.

 

I'm not totally against the larger distribution,

What I'm not in support of,  is time spent on a duplication vs new features we cannot do ourselves.

 

Interesting thread 

 

The packages included with unRAID are selected to be a good tradeoff between what is required for NAS, and what is desired from a user customization point of view.

 

For those who want to install other rather large packages, we have increased the max memory supported from 1G (actually 1G-128M) to 4G - so if you need more memory, it's far easier to just add RAM than try to prune the root ram-disk further.

 

 

What your failing to see is the time involved ongoing, to supporting 2 distributions.

I'm talking about customer support, not the "10 minute" programming support.

 

It really shouldn't be that big a deal.  Basically just say that only the unRAID part itself is supported.  If you have trouble with 3rd party programs then you're on your own (as far as official support, of course you'd be welcome to post in the forums for user support).

 

There are going to be umpteen questions, the first always being which distribution.

 

That'd be a question that we, the users would ask someone posting in the forums, and only if the poster is trying to run 3rd party stuff.  If they have troubles getting their hard drive recognized, that's a core unRAID issue, doesn't matter if they're running -minimum or -max.

 

From what I remember, there is a thread around that shows how to extract bzroot to the hard drive.

Add your packages to the directory, then repackage bzroot for placement onto your USB key.

 

That's too time consuming, plus you have to do it for every single new distro.  We're up to beta3 on 4.3 now, so if you wanted the latest and greatest that'd be three times going through all that in just the last few weeks.  Plus I'm 99.99% sure there's going to be at least one more beta with some new cool features added (no concenated partiy drives), plus at least one more for final (if not more betas).

 

Anyways...

 

I would love just throwing it all on a regular hard drive.  For my needs, a drive is going to be used quite often anyways (anytime we get a call new call logs are generated that need to be permanently saved, plus call logs, changes to the asterisk database, etc.).  There's no need for me to have it running off a flash drive/ram just so all the drives can be spun down.  I'm sure there's others out there like me too.  This would be quite a bit more of a support headache than my original proposal, but probably much more rewarding too.

Interesting thread 

 

The packages included with unRAID are selected to be a good tradeoff between what is required for NAS, and what is desired from a user customization point of view.

 

For those who want to install other rather large packages, we have increased the max memory supported from 1G (actually 1G-128M) to 4G - so if you need more memory, it's far easier to just add RAM than try to prune the root ram-disk further.

 

 

True, but this was an idea to help those who are just fine with what they have now but still want to upgrade (so they want to keep running with minimal ram, don't want to have to upgrade their usb flash drive, etc.) and those of us who have the latest and greatest.  Like I said it doesn't affect me, I have a dual-core cpu (just waiting for smp, or I may just recompile myself), 4GB usb flash drive (not the largest, but should handle unRAID for a loooooong time), and 2GB RAM (would have gone for 4GB, but I bought just before you announced support for more than 1GB RAM).  Now if you make it so there's an option to install to a hard drive (like a livecd), then that would just be awesome.

In particular, no development time would be spent deciding and testing what things can safely be taken away, and the beta cycle could focus on unRAID itself.

 

Not by a long shot.  If unRAID was installable to a Slack distro, Tom would have to test with several orders of magnitude more scenarios and deal with several orders of magnitude more headaches and conflict.  By limiting it to a self-contained distro, it works right out of the box.  Even so, there are still incompatibilities.

 

Or, are there compelling technical reasons for crippling Slackware?

 

Yes, there are.  unRAID runs from an initrafs and with no swap.  That means every meg of RAM of files you ad to the distro, is another meg of RAM you don't have to use.

 

As I said, for anyone adequately skilled in Linux, they can put applications on the hard drive, add swap, compile their own kernel and applications, and make whatever bloatware they want.  The people skilled enough to do so won't pester the rest of us with noob questions.

 

Making it too easy to modify unRAID would make things worse from the standpoint of support.  And as a software developer myself, I can gar-ran-damn-tee you that support like that is a nonproductive black hole that will consume every possible millisecond of space-time and sucks the life out of you.