unRAID wiki and docs

[RobJ]

 

By request, this discussion was split off from here, specifically after this post.

 

 

Set the boot order to as follows: Forced-FDD, USB-HDD, USB-ZIP

Try disabling USB 2.0 support (this will default to USB 1.1).

Try switching on or off any Fast Boot feature.

Try Switching on or off USB keyboard support.

 

This bit of advice is in the V6 manual but not on the page linked by RobJ

First time I've ever seen those tips (don't know who came up with them), which is why they aren't on the old wiki page.

 

(why is the documentation so spread out took me forever to sift through it and woke out which bits are still valid)

Are you volunteering to help organize and update the docs?   

[garycase]

Set the boot order to as follows: Forced-FDD, USB-HDD, USB-ZIP

Try disabling USB 2.0 support (this will default to USB 1.1).

Try switching on or off any Fast Boot feature.

Try Switching on or off USB keyboard support.

 

This bit of advice is in the V6 manual but not on the page linked by RobJ

First time I've ever seen those tips (don't know who came up with them), which is why they aren't on the old wiki page.

 

 

Not something I'd add to the Wiki => that sequence is very BIOS specific.    The important thing to note in the Wiki is to be sure you've set your BIOS to boot from the USB flash drive first ... and perhaps include a note that the flash drive MAY be seen as a hard drive in some BIOS implementations; and if that's the case you need to be sure it's listed as the first hard drive in the boot order.

 

[m0t0k0]

Are you volunteering to help organize and update the docs?   

If I'm still here in a year I may have enough knowledge to be of some small help

 

Having come from flexRAID where the developer would reguarly dissappear for months at a time

I was really impressed at the ammount of documentation and cummunity around unRAID.

 

Its just a little spread out and difficult for a newbie to determine what is old, like reading up how to run a pre clear script only then to find I can get it as a plugin.

 

 

Not something I'd add to the Wiki => that sequence is very BIOS specific.    The important thing to note in the Wiki is to be sure you've set your BIOS to boot from the USB flash drive first ... and perhaps include a note that the flash drive MAY be seen as a hard drive in some BIOS implementations; and if that's the case you need to be sure it's listed as the first hard drive in the boot order.

Seems to me to be better off in the trouble shooting section. As you would want the manual to say do this to make a USB drive and if that fails go here (to a page with all USB boot/creation infomation & tips)

[RobJ]

I was really impressed at the amount of documentation and community around unRAID.

 

Its just a little spread out and difficult for a newbie to determine what is old, like reading up how to run a pre clear script only then to find I can get it as a plugin.

 

I completely agree.  But that's what happens with a community of volunteers.  Preclear is a good example, with perhaps half a dozen different people involved in some way at some point.  And those who help in the development part are often not the best at the documenting part.  unRAID is now into its third generation (Preclear in its second generation), and there's a huge backlog of docs needing updating, and there's nothing fun about it to attract volunteer user involvement, unpaid users with their own lives to live.  And Lime Technology is a very small company.

 

Much of the documentation was written by users who knew they weren't great writers, but felt it was better to write something than have nothing.

[Fireball3]

I can fully understand beginners.

I'm also aware of the history and how it became how it is now.

It's OK, there is no one to blame about it, but we should also recognize,

that action has to be taken sooner or later!

 

Let me adress some points (maybe shift the post to a dedicated topic?):

 

The first thing we lack is a v6 exclusive wiki.

I'm speaking of the user contributions, the Official one is split.

 

Having a mixed wiki leads to massive confusion.

If there is no information in the new wiki, you know what you're up to.

 

Also, editors are scared to delete or modify content.

Better to start a whole new wiki imho.

 

Regarding forum posts, even more hairy.

I don't know what tools are available in the forum framework used.

Mabe we can have an "Osolete" stamp!?

Or have some more tags like the "Message icon" to adress "valid for unRAID version" or "period of validity".

 

Sometimes a head-crash can be a blessing as it helps to start over. 

 

[garycase]

... The first thing we lack is a v6 exclusive wiki.

 

Absolutely.  This is perhaps the biggest issue [Not only v6, but also a lot of the various user contributions behave differently in different versions, and that's not always clear -- unless perhaps you read through an xx-page forum post, where xx is in some cases dozens, or even hundreds, of pages ... i.e. something no beginning user is likely to do].

 

But we can't (or at least certainly wouldn't want to) change to an all new Wiki that ONLY addresses v6 ... there are still a lot of users on v5, and I suspect even a fair number on v4.7.    It's a gross simplification; but in simple terms -- for those who only use UnRAID as a NAS (it's original purpose, and still its core) -- there's no compelling reason for a v4.7 user to upgrade unless they need disks < 2TB;  and there's no compelling reason for a v5 user to upgrade unless they want to use virtualization and/or dual parity.  The v6 upgrade does have a lot of less compelling reasons to do -- a much improved GUI and XFS support for example -- but those come at a cost in required CPU "horsepower" and additional memory demands, which for some may be a good reason to stay with v5.

 

Sure, it'd be easier for Limetech (and the forum) to provide support if EVERYONE was running the latest version ... but in some cases that's not possible (there are a few users still running 32-bit hardware); and in others it's not desirable (users running older systems that would perform poorly with the much-more-CPU-intensive v6).  Just like Microsoft would prefer that all of their users were on Windows 10 (and they tried mightily to induce that with their year-long free upgrade) => but there are still a LOT of folks running Windows 7, 8.1, or even XP.

 

Nevertheless a v6-focused section would certainly be a good idea, and is perhaps a good goal for the evolution of the Wiki content, as long as there's still a "legacy" section to cover the earlier releases.

 

[RobJ]

There's actually quite a bit of v6 wiki content, and it seems to me to be completely unrealistic to consider throwing it all out.  What may be needed is a top level v6 page that accumulates/organizes/coordinates it all.  I've thought about combining the old Getting Started with unRAID page with the Unofficial Documentation page, updating it all for v6, and adding a comprehensive site map to all v6 pages.

 

Starting over just doesn't seem possible or realistic.  Then you are left with nothing, because there's very little writing that happens here.  With the current pace of wiki contributions, by the time there's a decent v6 wiki, we'll be on v8!

 

An idea, just throwing it out as a possibly workable model, develop all or most wiki pages in parallel, as the current page and the page for older versions.  Each current page would have a statement at the very top with a link to the parallel one for older versions, something like: "For older versions, see <Page for older versions>".  For example, the FAQ would have a line saying "For older versions, see the <FAQ for older versions>".  This would be something we could do realistically, over time, slowly converting current pages.  And when v7 comes out, more stuff would move from the current page to the parallel page.  Only the parallel page would contain delineated sections for the various unRAID versions.  This way, we always point users to the current wiki pages, and if we're consistent, they will find their way to the correct info for their version.

[garycase]

Definitely did not mean to imply starting over at all => just making it clearer in some cases which things only work in v6, vs. those that work a bit differently in previous releases (or not at all).    For example, when doing a drive rebuild, it used to be necessary to stop the array; unassign the drive; then start the array so the drive is shown as missing; then you could stop it, assign the replacement, and start it up to do the rebuild.    With the latest release the initial stop/unassign/start isn't needed.    The old way still works -- so I always suggest that when folks are doing a rebuild so if anyone is using an older version and sees the instructions they'll still work ... but it isn't necessary.

 

Not sure what the best way is to differentiate different actions across versions -- but those are the kinds of things I have in mind.

 

[RobJ]

I probably shouldn't have put 'starting over' as strongly, I spoke too quickly based on what Fireball3 said.  And I imagine he didn't mean it literally, to scrap everything, but more as figuratively starting the whole thing over.  Which we can do by replacing the top level of the wiki, the starting pages, from which the other pages branch off.

 

But we do send users all the time to individual pages.  Two current examples, done in two different ways, are the FAQ and the Check Disk File systems pages.  The FAQ is a conversion of the old FAQ.  The conversion is incomplete still, but once finished it will be entirely for v6, with all older stuff relegated to the older FAQ for unRAID v4 and v5 page.  The Check Disk File systems page instead combines the old and the new in one page.  It tries to direct you to the correct section based on your needs *and* your unRAID version.

 

I know most think that the old pages are completely useless, but that's not what I have found.  Much of the information is redundant between the new and old wiki pages.  The differences are often significant, but they generally are also small.  When I started updating the FAQ for v6, I thought I would probably be deleting a lot of stuff, but that hasn't happened.  Many FAQ entries are the same, and most of the others just needed little changes, due to small methodology changes like the example Gary gave, or perhaps links updated for newer content.

[m0t0k0]

 

Well this prompted me to go and look at the old and unoffical documentation

 

There is so much info in there that I would have liked to have found when I was starting out.

It's a bit jumbled up and only now after a week reading and messing with V6 dose it make much sense. But it is there!

 

I think the most important section to get right is the UnRAID 6/Getting Started page.

Most new useres will use the current release

This is a very risky time if you have data populated drives

First impressions are very important

Ultimatly the goal is to convert trial to paid and grow the community

 

Unfortunatly the UnRAID 6/Getting Started page is missing some essential getting started topics!

Root password

CA

Pre clear

Data migration

 

Can anyone edit the wiki? If so what is the point of splitting between official and unofficial?

 

 

 

[RobJ]

Unfortunatly the UnRAID 6/Getting Started page is missing some essential getting started topics!

Root password

CA

Pre clear

Data migration

Thank you for that list, that helps!

 

Can anyone edit the wiki? If so what is the point of splitting between official and unofficial?

Anyone that has registered on the unRAID forums can edit the wiki.  I always recommend reading Start Contributing to get a feel for how it's done.  For anyone with any professional experience or programming experience, editing our wiki is child's play, baby stuff, really easy.  I've never understood why so few have tried it.

 

As to the split, long ago when the wiki was started, Tom of Lime Technology wanted it that way.  Wikis were new, and he probably didn't have much confidence or trust in allowing unknown users to freely write material that ultimately represented him.  Over time, we've gained a lot of trust, and we take the responsibility very seriously.  I and others monitor it constantly, watching for abuse, reviewing every change - not for competence, but for abuse or inaccuracy.  We haven't spoken to him or Jonp recently, but it still seems a wise distinction, delineating what is official and what is user-contributed.  In fact, I think the community (in the past!) has felt proud of what we've accomplished.  Unfortunately, it didn't keep up with all the changes.  The software keeps growing, and I keep getting overwhelmed.

[RobJ]

I should add that Tom has announced that the forums and wiki are all moving to new software, and that may involve wholesale changes.  I don't believe we should hold off updating what's currently there, but does mean big changes are coming.

[JonathanM]

big changes are coming.

Soon™

 

Prior history predicting future events, I'd estimate looking for changes in 2018.

[trurl]

I was really impressed at the amount of documentation and community around unRAID.

 

Its just a little spread out and difficult for a newbie to determine what is old, like reading up how to run a pre clear script only then to find I can get it as a plugin.

 

I completely agree.  But that's what happens with a community of volunteers.  Preclear is a good example, with perhaps half a dozen different people involved in some way at some point.  And those who help in the development part are often not the best at the documenting part.  unRAID is now into its third generation (Preclear in its second generation), and there's a huge backlog of docs needing updating, and there's nothing fun about it to attract volunteer user involvement, unpaid users with their own lives to live.  And Lime Technology is a very small company.

 

Much of the documentation was written by users who knew they weren't great writers, but felt it was better to write something than have nothing.

This thread brings to mind what a great asset the loyal and helpful community is to this very small company. I wonder why none of the "competition" ever developed a similar loyal and helpful community? I have said many times that the forum is the reason I chose unRAID.

[JonathanM]

I wonder why none of the "competition" ever developed a similar loyal and helpful community? I have said many times that the forum is the reason I chose unRAID.

Personally I believe it's because Tom chose to NEVER release software with a known major issue, despite being hounded and browbeaten to hurry up and release new stuff. It's honestly the only software I know of that has such a stellar track record of major releases staying stable and usable for such a long time. Plus, the "lifetime" license that we currently enjoy means that once a member, always a member. No incentive to leave the fold in search of a better product, because we keep getting all these awesome upgrades and improvements for free.

 

I fear for the long term financial health of the company, but for the near term, evangelism and new features seem to be driving healthy growth. At some point, I expect we will see one of two things. The end of the free upgrade gravy train, or the cessation of development. Limetech can't survive without ongoing income, so at some point we will reach market saturation and new licenses won't sustain development.

 

Let's hope if they get to that point they make the decision to charge a small fee for upgrades rather than closing.

[Fireball3]

I fear for the long term financial health of the company, but for the near term, evangelism and new features seem to be driving healthy growth. At some point, I expect we will see one of two things. The end of the free upgrade gravy train, or the cessation of development. Limetech can't survive without ongoing income, so at some point we will reach market saturation and new licenses won't sustain development.

 

Honestly, I've often thought of how it's possible to keep the business running with just a few lifetime licenses.

Yes, they also do sell hardware and stuff, but still - is it the big business?

I imagine it's not that simple to take another approach with licensing policy.

 

Considering a subscription scenario might scare people, to be honest, I wouldn't like it if it was mandatory.

Kind of, if you pay you can keep your data...meh.

 

Selling by "new features" will lead to the necessity of updating the old versions, for security reasons, for those who don't want/need "new features".

 

Another thing I can think of is a "crowd-funding" approach for new features.

 

We will see, until then I will continue spreading the word and building some servers for my friends.

Looking back, v5 was still a "nerd edition" needing shell contact for e.g. preclearing, adding various scripts for clean shutdown, whatever...

In v6 we are a huge step forward in terms of user-friendlyness and usability.

Massively contributed to by this great community!!!

It really helps in promoting the OS and increases the license count in the end!

 

I probably shouldn't have put 'starting over' as strongly, I spoke too quickly based on what Fireball3 said.  And I imagine he didn't mean it literally, to scrap everything, but more as figuratively starting the whole thing over.  Which we can do by replacing the top level of the wiki, the starting pages, from which the other pages branch off.

Exactly Rob, I didn't mean scrapping the old things. There should be a wiki for each version (v4, v5, v6).

The "Official Documentation" setup seems a legit approach as long as we don't have better ideas.

 

I know most think that the old pages are completely useless, but that's not what I have found.  Much of the information is redundant between the new and old wiki pages.

 

As already mentioned, we have to keep in mind, that there are people out there using older releases and we shouldn't delete the info, as they might need it again.

It's not really eating up that much space also.

 

Let's set up the branches.

Copy the whole thing into the v6 branch and then it's hopefully easier to update its content.

[m0t0k0]

Exactly Rob, I didn't mean scrapping the old things. There should be a wiki for each version (v4, v5, v6).

The "Official Documentation" setup seems a legit approach as long as we don't have better ideas.

 

The issue I had was I started with the official Docs but it was missing a lot of the information from the unofficial Docs.

 

My assumption was the official docs would be better for setting up and the unofficial better for customisation once I was up and running.

 

I think if there is going to be a separation like this then the official docs should take priority (difficult to do when it is community created)

 

 

As already mentioned, we have to keep in mind, that there are people out there using older releases and we shouldn't delete the info, as they might need it again.

It's not really eating up that much space also.

 

Let's set up the branches.

Copy the whole thing into the v6 branch and then it's hopefully easier to update its content.

 

Defiantly keep any old content (unless proven to be incorrect)

 

But I think splitting the information into version branches is a very wise idea.

This way when a new version is released you can just duplicate the previous branch edit the old stuff out and add in the new content with help from the community.

 

If I find the need to hide from the excitement over the Christmas period I will look at getting the V6 docs up to date in the areas I'm now familiar with

 

[RobJ]

The issue I had was I started with the official Docs but it was missing a lot of the information from the unofficial Docs.

 

My assumption was the official docs would be better for setting up and the unofficial better for customisation once I was up and running.

 

I think if there is going to be a separation like this then the official docs should take priority (difficult to do when it is community created)

 

A clarification, something I forgot to mention, the official docs are only edited by Lime Technology staff.  We users edit only underneath the Unofficial Documentation umbrella.  If they created it, we don't touch it.  Of course, you can email or PM them with suggestions.

[SpaceInvaderOne]

I fear for the long term financial health of the company, but for the near term, evangelism and new features seem to be driving healthy growth. At some point, I expect we will see one of two things. The end of the free upgrade gravy train, or the cessation of development. Limetech can't survive without ongoing income, so at some point we will reach market saturation and new licenses won't sustain development.

 

Honestly, I've often thought of how it's possible to keep the business running with just a few lifetime licenses.

Yes, they also do sell hardware and stuff, but still - is it the big business?

I imagine it's not that simple to take another approach with licensing policy.

 

Considering a subscription scenario might scare people, to be honest, I wouldn't like it if it was mandatory.

Kind of, if you pay you can keep your data...meh.

 

Selling by "new features" will lead to the necessity of updating the old versions, for security reasons, for those who don't want/need "new features".

 

Another thing I can think of is a "crowd-funding" approach for new features.

 

 

I think the best way for Limetech to raise more money would be to stagger new releases.

 

For example when 6.3/6.4 stable comes around. People should be able to pay say $15 to get the release staright away. If you dont pay the "early bird fee" then

it is released in the normal way a month later.

That way the lifetime licenses are honored and if we pay a little we can change from soon™ . to a bit sooner™

 

 

[JonathanM]

 

I think the best way for Limetech to raise more money would be to stagger new releases.

 

For example when 6.3/6.4 stable comes around. People should be able to pay say $15 to get the release staright away. If you dont pay the "early bird fee" then

it is released in the normal way a month later.

That way the lifetime licenses are honored and if we pay a little we can change from soon™ . to a bit sooner™

That feels a lot like paying for the privilege of being a beta tester. I always wait a while, at least a couple weeks, before upgrading anything. I don't like surprises, let others find the easter eggs, new features, whatever.

 

Not saying I don't agree with the idea, it would benefit my personal methodology. Just that the perceived value in being first is definitely an individual philosophy thing.

 

So, to expand on what you are saying, public beta participants would be getting the latest releases for no additional cost, but to have the privilege of renaming the last RC to Final a few weeks early would cost $$? And anyone buying a new license in the upgrade window would get the Final, but existing license holders would have to either continue running the last RC or pay the premium until it was public release?

 

Sounds complicated and possibly contentious.

[SpaceInvaderOne]

 

I think the best way for Limetech to raise more money would be to stagger new releases.

 

For example when 6.3/6.4 stable comes around. People should be able to pay say $15 to get the release staright away. If you dont pay the "early bird fee" then

it is released in the normal way a month later.

That way the lifetime licenses are honored and if we pay a little we can change from soon™ . to a bit sooner™

That feels a lot like paying for the privilege of being a beta tester. I always wait a while, at least a couple weeks, before upgrading anything. I don't like surprises, let others find the easter eggs, new features, whatever.

 

Not saying I don't agree with the idea, it would benefit my personal methodology. Just that the perceived value in being first is definitely an individual philosophy thing.

 

So, to expand on what you are saying, public beta participants would be getting the latest releases for no additional cost, but to have the privilege of renaming the last RC to Final a few weeks early would cost $$? And anyone buying a new license in the upgrade window would get the Final, but existing license holders would have to either continue running the last RC or pay the premium until it was public release?

 

Sounds complicated and possibly contentious.

 

uum it seemed like a good idea at the time when I wrote that...........But now I agree with you!!