I have found mcedit caused my a few headaches with files this week.

What issues?  I am generally curious as I have been using mcedit since I have been using unRAID and have never had an issue with it nor has it caused me issue, that I can remember.

 

With my Shellinabox plugin I load my telnet session up in a browser and then start using mcedit.  That has worked beautifully for me.

Real geeks use vi, or edlin.

Real geeks use vi, or edlin.

quoted for truth

I thought vi was the only texteditor that came with unRaid

 

 

Skickas från min iPhone via Tapatalk

Found the NFS problem, fixed in -beta4.

Here is a workaround.  First, in the webGui select the disk/share you are exporting via NFS.  Next change the security mode to "Private".  Then in the Rule field enter this:

*(sec=sys,rw,insecure,anongid=100,anonuid=99,all_squash)

Click Apply.  Your NFS client mounts should work now.

 

Woot!  OK, I've been looking for an excuse to post this....

 

Thanks Tom...and thanks for all the fish!!

Real geeks use vi, or edlin.

 

quoted for truth

 

[glow=red,2,300]Certified Studs like me use nano (Chicks dig us and nano too).[/glow]

 

If we really want to go all out and make unRAID dork / geek friendly...

 

Let's switch over to Gentoo, forget plugins and compile our packages from source.

 

With every unRAID "Gentoo Edition" purchase... Tom will include:

 

1. A pocket protector.

 

2. Dorky classes with tape in the middle.

 

3. Short sleeve button up shirt that is too tight and a ugly clip on tie that is too short.

 

4. A subscription to your "adult site" of choice because it's probably a save bet that you haven't seen someone from the opposite sex naked in real life and probably never will.

 

5. Think of all the fun we will have showing off our make.conf and our custom CFLAGS & CXXFLAGS for how we compile everything. This is Geek / Dork Porn at it's finest.

 

 

I probably shouldn't be jumping into this, so just consider this the forum equivalent of me poking my head in the room and then running for my life ... or consider it an honest question of curiosity:

 

Is nano that much better than the editor already included in Midnight Commander?

 

I have found mcedit caused my a few headaches with files this week.

 

Nano just works and is so tiny. Can't believe the intensity of debate over nano!

 

 

I have no problems adding nano, I use it myself. However I do fundamentally believe we should not require users to go to the command line for normal operation. This is the way it has always worked and I am yet to see a reasonable argument otherwise.

 

Given the fact that i firmly believe the majority of user should never be on the command line and therefore should never need nano I liked the idea of nano be a  simple and useful example addon.

 

So the question is not "why argue against nano" it is "why are we changing the default config design we have had for ever"

So the question is not "why argue against nano" it is "why are we changing the default config design we have had for ever"

 

I'm going there NAS... good thing humans weren't thinking that way when they invented the round wheel.

 

 

Anyway, I played around with unraid6 and xen last night, and everything worked perfectly (well, had to edit syslinux.cfg because I didn't have enough ram, but thats my config) so kudos to Tom & everyone else who got this going.

 

As for the nano debate, I'd love to see nano included by default. I just toss the slack package in and install on boot. I'm a nano-fanboy. Small, fast, easy. I hate vi and while mc works, I just don't need all the other things it can do.

 

Until nano is in can we (noobs) use the editor from mc? I think unRaid comes with mc by default.

Seems like once a plugin in created for editing vm CFG's this editor debate will be alot less prevalent for most people.

However I do fundamentally believe we should not require users to go to the command line for normal operation. This is the way it has always worked and I am yet to see a reasonable argument otherwise. Given the fact that i firmly believe the majority of user should never be on the command line

 

Wait... What?!?!?!

 

There is a preclear plugin? A preclear plugin that also installs screen so I can preclear 2 or 3 drives at once?

 

There is a plugin that will custom compile a Kernel and add my TV Card?

 

There is a plugin that runs Resier fstack tools?

 

There is a plugin that installs unmenu?

 

Someone please post a links to all these plugins (hope to God they work and don't crash my Server like the rest of the plugins do) so I can avoid going to command line from now on.

 

therefore should never need nano

 

I need nano, the people who will use my guides / VM Appliances will need nano. If I have I to post a bzroot along with my Guides / VM Appliances... so be it.

 

In the meantime, will you or someone else write a WebGUI / plugin (that always works and doesn't crash my Server) for Xen / KVM, preclear, fstck, nano, unmenu, screen, Pxe Server, etc?

 

I liked the idea of nano be a  simple and useful example addon.

 

Since plugins works so well and people are literately begging / pleading / offering money for someone to fix / create / modify existing ones...

 

How much of a reward are you personally going to put up for someone to write a nano plugin?

 

Make it $100 at least so I have it today.

 

That way, I don't have to upload my own bzroot along with my XBMC Appliance.

 

So the question is not "why argue against nano" it is "why are we changing the default config design we have had for ever"

 

Three of my family members who have an unRAID Server... Do not know Linux and do not want use the command line.

 

1. They are FORCED too if they want to preclear drives, install unmenu, run fstack tools and a bunch of other stuff.

 

2. They spend God knows how much time trying in command line to figure out / fix the screwed up plugin system (that everyone here and their brother knows doesn't work and will probably crash your Server).

 

3. Yet here you are pushing a flawed / unreliable / broken pile of shit plugin system.

 

4. Who is going to write this nano plugin?!?!?! We ran off the plugin developers and only a few people are bothering patching / updating plugins. A new one hasn't been written in how long? A year?

 

5. 534kb of space that almost every Linux Distro has and 90% or more of any guide / documentation / Wiki you see on the web uses nano.

 

What is your solution?

 

Halt unRAID 6.0? Rip Xen out of it until a Plugin / WebGUI exists?

 

Good luck with that... I do not see either one of those things happening.

 

Look how much money Tom has made with just the users who posted in $30 Limited Time Offer Thread and took advantage of it. Are you personally going to refund all those users (and the ones we don't know about) who purchased unRAID at that special price their money?

 

I bet that cost you several thousand dollars. Is preventing Tom installing an App that 95% of us want and 534kb of space really worth that much trouble / cost?

Who cares if nano is added to unraid!?  If you don't need it, don't use it.

 

One of the fundamental issues with unraid is that it's why behind the times and a lot of IT pros/power users avoid it for more flexible options.  Making unraid more IT friendly by adding OPTIONAL and industry STANDARD tools, Tom can expand his user base.  In turn this will add more experienced and knowledgeable users to our community and instead a couple guys making appliance VMs, repos, plugins, etc we could have hundreds.

 

All the stuff being added to unraid is going to make it a better product for everyone.  Stunting progress because some users don't understand how it all works is not a good reason.  Tom isn't going to release 6.0 final without the required documentation for every user to understand these new features.

SchoolBusDriver take a breath, no need to write a zillion words for everything.

 

Request nano if you like, have it added if you like but we have a config system already and it has worked for years and doesn't require nano.

 

It really is simple... unRAID config does not require the use of the command line and once we get out of beta it shouldn't again.

 

 

SchoolBusDriver take a breath, no need to write a zillion words for everything.

 

Request nano if you like, have it added if you like but we have a config system already and it has worked for years and doesn't require nano.

 

It really is simple... unRAID config does not require the use of the command line and once we get out of beta it shouldn't again.

 

Dude, some people prefer using the CLI.  Actually most, if not all, linux users do.

I would suggest presenting it to Tom with supporting points.

I asked for curl for us as I know we'll be able to automate http gets/posts, ftp gets/posts and other protocols. SMTP, etc, etc. 

 

It would be nice if we could edit the files right from the webgui.

Are there small lightweight editor apps for php that would work in our environment?

 

A long long time ago...  I struggled with vi, cursing it all the way. I forced myself to know it since every platform had it.

I went as far as changing my dos editor to a vi clone to really force it down my throat. It was a hard pill to swallow. LOL.

 

Seriously though, if nano is going to be easier, lightweight and resolve the CR/LF problem, present it to Tom directly.

No need for soliloquy in this particular thread. If we need to debate it's merit, the discussion should be forked.

Dude, some people prefer using the CLI.  Actually most, if not all, linux users do.

If you are advanced to the level that prefers using the CLI, it's simple to install nano yourself. Why raise a huge stink about something that takes 5 minutes, max? If it gets installed by default, fine, if you have to install it yourself, that's fine too. No need to get all worked up about it.

SchoolBusDriver,  Dephcon >> relax,

although you both have a good arguments here, "nano" missing from the unRaid is not the end of the world.

 

users who like/prefer to use CLI usually can install it them selfs.

other will wait/request for it to be added to the setup or find a way to replace it.

 

version 6 is a big overhaul of the system in general and it will take time until all the small things are figured them selfs  out.

 

I frankly would  love the unRaid to be converted into a full distro based system

preferably OpenSuse as I do like that one very much.

this way you could even add a GUI with Yast to it.

but it is not likely to happen.....

Indeed a config interface fork is required because this is starting to reek of:

 

 

SchoolBusDriver,  Dephcon >> relax,

although you both have a good arguments here, "nano" missing from the unRaid is not the end of the world.

 

It's not?

 

users who like/prefer to use CLI usually can install it them selfs.

other will wait/request for it to be added to the setup or find a way to replace it.

 

If a user wants to preclear drives, install unmenu, add their TV Tuner Card, use VMs... They don't have choice but to use CLI.

 

Unless someone hid plugins for the above that will further blow up my semi-working plugins / crash my server.

 

I frankly would  love the unRaid to be converted into a full distro based system

preferably OpenSuse as I do like that one very much.

this way you could even add a GUI with Yast to it.

but it is not likely to happen.....

 

Uhhhhh... If there is a passionate and robust debate on whether a default 534kb text editor should be added to unRAID or not... Your Full Linux Distro in openSUSE dreams don't have a snowballs chance in hell of ever becoming reality.

 

Imagine how many people would be banned and the number of threads that would be closed / deleted over which checkbox is selected for the Linux Desktop. It would be Biblical!

 

Even though you could choose / select another Desktop or none... The fact that I suggest KDE or Enlightenment or XFCE be the default checked or someone else suggests Gnome or Cinnamon be the default checked... would literally cause some people on here to run into the streets screaming naked or perhaps even commit suicide.

Thant was my thinking with the request - a tool to use during this beta period to help with setup, guides etc. It's a PAIN to be at unRAID CL doing stuff and then have to move off to another environment to edit a text file.

 

You could use vi, which is included in unRAID builds! 

 

For an oldie like me, who was computing before the era of graphical interfaces, vi is a perfectly good editor!

Thant was my thinking with the request - a tool to use during this beta period to help with setup, guides etc. It's a PAIN to be at unRAID CL doing stuff and then have to move off to another environment to edit a text file.

 

You could use vi, which is included in unRAID builds! 

 

For an oldie like me, who was computing before the era of graphical interfaces, vi is a perfectly good editor!

 

I'm sorry but you misspelled, "Git off ma' lawn!!!!"

 

There FTFY 

I wasn't aware that nano had dependencies. On unraid 5.x I just dropped the slackware package into /boot/extra and it worked. I guess other plugins took care of the dependencies

I can't believe I've gotten to sift through 2 pages of debate on nano in the announcement forums. Off topic much?

 

On a slightly more on-topic topic I upgraded from 5.0.5 to 6.0-beta3 (used a new key so I didn't carry over the legacy crap other than disks/shares, etc).

 

Everything is running smooth and better than 5 was. I had reported in the 5.0.5 thread that after upgrading from 5.0.4 I was having performance issues - mind you I had swapped MB/CPU and the new system has 16GB ram, which may have caused some/all of my issues.

 

I was getting parity checks of 30-40MB on 5.0.5, and with Tunables I was able to get 85MB. On moving to 6.0 with Tunables I am able to get 113MB so am happy with the current config. It also appears that pre-clearing a disk and running parity check doesn't bring UnRAID to it's knees like 5.0.5 was doing for me.

 

I also have to say I like the new GUI as it's the first real chance I've had to sit and use it.

Since we are all having a robust / fiery debate about nano... Let's talk about something more serious.

 

As it stands right now, unRAID 6.0 beta2 to beta3 went from 256MB of total ram to over 512MB.

 

We haven't even gotten to KVM which has A LOT more stuff than Xen does which I would expect to push it over 1GB if we continue to use a root ram file system.

 

An few suggestions to fix several things at once...

 

1. Quit trying to put EVERYTHING under the sun in a bzoot.

 

2. Create dual partitions on a USB Flash drive via an ISO.

 

3. Partition 1 - VFAT - All the stuff that Tom / Users needs to access / configure / etc.  in unRAID via Windows and Mac. (NFS Shares, Password, Shadow, Disk Settings, Key file, etc.)

 

4. Partition 2 - EXT4 (noatime and no journaling) and put the rest of Slackware on there.

 

5. Tom would put A LOT of Slackware stuff that is static in the bzimage but put things like /lib64, /usr, /bin, /sbin, etc. on the EXT4 Partition. Together both would appear / be one normal looking root file system.

 

6. We could keep the RAM used by Slackware to a minimum like it is now. You would not have the program and the amount of space it takes up on a Flash Drive getting loaded into memory.

 

7. People would only have to load something ONCE. For example, we settle on perl version X and python verion Y and zlib version Z and put those in the second EXT4 partition.

 

8. This would solve 80% of the BS that plugins developers / users have to deal with like downloading and installing 6 different versions / kinds of perl or python, zlib, etc. from who knows where.

 

9. Since there isn't that many Plugins, edit the plugins to load only the program itself at each boot and not all the various core Linux apps / libraries that each Plugin Developer decides.

 

10. It makes adding something like KVM less painful and it doesn't take up our RAM do to only having a root ram file system.

 

11. It's writecycles that "wear out" a flash drive... not reads. A $5 POS USB Flashdrive has 100,000 writecycles and how many times do you think someone is going to be installing NEW packages in Slackware after they loaded them once?!?!?!?!

 

12. Tom could keep an "image" of the default EXT4 Partition on VFAT4 partition where a user could run a batch file or click an option in the WebGUI that overwrites it and makes it default / vanilla again if something went wrong. The config / settings / etc. would remain untouched on the VFAT Partition.

 

13. How many people have 256MB unRAID Flash Drives? I personally buy any of these users a $5 4GB (or more) if this is would be the hang up to the above.

 

SchoolBusDriver >>  you are right about UnMenu and Preclear

this functions should have been added and available from webGUI all along as they are directly related to UnRaid operations

Pre-Clear is a MUST DO for any and all drives you adding to the array

and unMenu is a plug-in to improve stock GUI as well as add functionality to it.

 

however until now (V6) VMs where only user choice not a built int function.

as this is a new thing, Tom will need time to figure out what is needed and how to implement it.

 

as for my lounging for a full OpenSuse based distro :-)

well I like to dream, but I know where the dream stops and reality kicks in