Don't vi on me and tell me it's raining! Where's pico?

[tkaiser]

... pico editor ( on PineA64 gnu+linux , which is debian based, including armbian ) is nano. I'll let tkaiser speak for armbian

Armbian is not a distro but a build system supporting 2 Debian and 2 Ubuntu distros. Package vim is contained in the 'non-essential packages' list and nano in the 'release specific packages' for both Ubuntu variants since it's missing there for whatever reasons. For our users it should make no difference whether they're currently running a Debian or an Ubuntu variant so both editors are always installed (and the usual nano --> pico link is created).

That nano/pico are included in Debian images is because there it's part of the minimal install and that it's missing in 'official' Ubuntu Xenial images here is just result of no one thought about and added it to the list of packages (longsleep's original Xenial image is as minimal as it can be, Pine64 folks just fiddled around to add a desktop environment for their 'official' Ubuntu image). There's no need to defend that the package is missing it's just no one took care of. 

That's all (and that's the reason why I contribute to Armbian, since I hate surprises like those, I want to have the same environment on every SBC I deal with regardless whether Debian or Ubuntu is running. According to our users those two editors are what the majority needs, at least no one complained so far that any other package listed by aptitude search '~Peditor' would be missing in a default install)

[tampadave]

Thanks tkaiser, my original problem, which is why I posted, was because pico/nano wasn't on the dd image that I was using.  I needed to configure my wifi, and to configure my wifi, I needed the use of an editor.  

For the record: pico/nano are functionally, the same thing.  vi/vim are functionally, the same thing.


I'm glad we're getting nano onto these images (are we?).  My concern is that for someone new to this, >everything< is new, and formidable.  nano knocks down the editor issue at a very crucial point in a new user's quest to build their own pine64.  I do not want people to think that vi is representative of the state of this technology.  

At the startup/build stage, things are rightly limited in resources, because the only thing you're doing is getting the system ready to finish it into the purpose of the system build.  It is strictly prep.

Once you've got your pine64 in a stable, networked state (the single purpose of these installation images), you are ready to complete your pine64 as a desktop, server, cluster blade, embedded computer, ....  

Now for the man pages...

[MarkHaysHarris777]

For the record: pico/nano are functionally, the same thing.  vi/vim are functionally, the same thing.

For the better record:  (at least on our images) pico IS nano,  and vi is NOT functionally the same as vim; which is why vim is named, " vi improved ".   To be a little more precise, if you envoke pico you actually start nano, and if you envoke vi you are actually starting vim ( vi's improved and more highly functional big brother ).

[tkaiser]

I'm glad we're getting nano onto these images (are we?).

If you refer to the 'official' stuff featured here with 'these images' then I doubt that you get nano anytime soon with Ubuntu. I was referring to a community project that relies on experiences and knowledge from other communities and tries to concentrate all of this in an automated build system able to spit out OS images for a 'few' SBC (+40 now) supporting for most of the devices at least 2 different kernels and for all devices 4 distros.

For me it makes absolutely no sense why dealing with an SBC should feel different when running Ubuntu than when running Debian. That's why we take care that that's not the case, I simply don't have to care that much whether I boot with one or the other. Nano will always be there as will be vim.

And the whole idea behind is to choose the hardware that fits the use case (software behaving more or less the same) and not the other way around (when you want to avoid specific SBC since the available OS images are so horrible even if the hardware is nice).

BTW: On recent Ubuntu and Debian distros you should get 'real' vi behaviour by using this 

Code:

alias vi="ex -v"

I forced myself to use the 'restricted mode' even in OS X just a decade ago since back at that time the software environment at some customers was horrible (DG/UX, Solaris, HP-UX, IRIX all shipped with vi and not vim). Not necessary any longer...

[MarkHaysHarris777]

I'm glad we're getting nano onto these images (are we?).

For me it makes absolutely no sense why dealing with an SBC should feel different when running Ubuntu than when running Debian. That's why we take care that that's not the case, I simply don't have to care that much whether I boot with one or the other. Nano will always be there as will be vim.

I agree with this sentiment also;  but I would expand ( at the risk of being pedantic ) the concept to one of simple expectation-- there are two use cases ( or populations ) who have expectations 1) the modal users and the 2) modeless users.  Both of these expectations needs to be met in a modern unix-like distro.

For this discussion the Single Unix Specification must be highlighted.  Compliant systems 'must' contain vi or the vim derivative ( and if it contains vim it must be able to run in 'compatible' mode ) which means that vi in it's base form must be there;  its not optional. Modeless editors , on the other hand , do not share that same prestige nor history. Regardless, anyone responsible for maintaining a 'system' or build process must keep the intended audience clearly in mind-- like any author !  

If we satisfy the user population use case expectations ( in this case modal and modeless ) then we have met the challenge for consistency AND heterogeneous deployment, in a modern sense.

[tkaiser]

If we satisfy the user population use case expectations

'We'?

Unfortunately I've not the slightest idea how to influence the OS images that rotten over there without any updates or fixes since months: http://wiki.pine64.org/index.php/Main_Pa..._by_Pine64

No one responsible cares about stuff like that. The main problem is still called ignorance. And I doubt this will change anytime soon.

[MarkHaysHarris777]

If we satisfy the user population use case expectations

'We'?

Unfortunately I've not the slightest idea how to influence the OS images that rotten over there without any updates or fixes since months: http://wiki.pine64.org/index.php/Main_Pa..._by_Pine64

No one responsible cares about stuff like that. The main problem is still called ignorance. And I doubt this will change anytime soon.

( my emphasis on 'We' )  ... mostly an English use , meaning of course the 'Royal We' who are the gnu+linux community in all of our collected strength as shakers and movers, idea makers and first adopters, and especially all of us who with only the slightest hint are changing the world in an irc chat room with a simple turn of phrase.  As a key player in that 'Royal We' , Tom , you have more influence than all the CEOs or architects out there;  and you leverage that influence every day. 

As I've stated already , I could care less which editor of choice is leveraged by any specific individual or whether modern educators think vim is outmoded ( pun intended ) but I do care that population expectations are met within the community.  The good news is, it seems like they are , and that's a good thing !

[tampadave]

Hey Mark, "( at the risk of being pedantic )" too late!!!   ROFL!

:-)

Quack (duck, rhymes with...truck) Unix/AT&T.  Presitge?  Quack quack.  No such thing.  I was supporing OS/2, tcp/ip and cm/2 for IBM (and their internal customers) back when OS/2 and CM/2 were still viable products.  tcp/ip was newly exposed to the general public, no longer the private domain of NSF net, DARPA, dot mils and dot edus.  I took that job because I believed that IBM was going to actually stay with OS/2.  Trouble is, IBM was so large, and still is, that (nearly) any twenty products of theirs could fail, and it would not matter. 

They made a financial decisions to kill OS/2, even though technically it was a very very solid product.  I do not respect corporate prerogatives towards technology.  I despise them, in large part, because they engineer incompetence into their designs, to screw money out of their customers.  Always have.  My understanding of evil, is willful incompetence.  I mean come ON!  How is it that after all these years, M$ still needs anti-virus software?  People think that is normal, and just keep paying because they do not know any better.  And they keep selling it.  M$ wanted a full license for each cpu core at one point. And many of these software businesses are trying to move to a marginal cost distribution, cause they figured out that fixed cost revenue reduces to zero in the long run.  (duh??) M$, adobe, others too I suppose.

I choose to be good, not evil.  I do not willingly participate in evil.  It is why I have my own company, so that I have a place I can work without violating my sincerities.

As for the pedantic nit pickeries of blah blah blah...  I am GNU/FSF/Linux all the way.  awk/gawk?  No.  awk is gawk so far as I am concerned, because: awk --version  GNU Awk 4.0.1, quack everything else.  Vernacularly speaking.  Pedantic nit pickeries are embarrassing if serious, funny if in rhetoric exaggeration. 

Fact is, I'd prefer not support at all, M$ questions, cause there is no good reason to, except for the fact that there are good people who do not yet know any better.  For many of them, we'll be able to "free them from the matrix" of bad technology by introducing them to good technology.  In this regard, I gladly value the people I might help, over my own disgust of those bad things they speak of.  It would be sooo easy for me to be a zealot, but I choose instead, to be helpful.  As best I can.

Responsibility is the (first) basis of liberty.  We are free to choose what we use, to do what we have chosen to do.  In OUR world, we are free and open to decide that for ourselves, cause we ARE the ones doing the work.  Quack all policies and practices to the contrary.  Unix, OSX, M$ and their subsequent derivatives.  No thank you.  Those people tell me what I can and cannot do, and how I can and cannot do them.  But for a price, those rules change.  No thank you.

Compliance.  Huh.  There are no standards in my free and open world, except for GNU/FSF/Linux, et. al..  Unix is non-compliant.  M$ is non-compliant.  In many ways, OSX is non-compliant.  Quack'em all.  I will not use their kit, so I neither need nor want it.  Mind you, M$ is the best gaming distribution, and very good for that.  I'm OK with that.  OSX is so close to GNU/Linux, that I prefer it over M$ when I am supporting a client, and Unix, well...  I've never been able to afford them, pre-MS-DOS or now.  And it is not just about the money, but sincere competence.  

To be one thing is to be nothing else.  I choose to be free and open, which means I am nothing else.  pine64 is free and open (except for quacking mali kit, for now), and nothing else.  kernel.org is free and open, and nothing else.  And so forth.

Finally, regarding distributions.  None of those are really different, other than the package and version management systems employed by those distributions.  At our build level use, we are in a GNU/Linux bash environment.  So if you were to label these "distributions" any thing, I'd label them bash distributions, cause that is what they are, regarding our purposes.  bash tools.  The bash tool chain(s).  "Build Environments" is probably the best term.  It's got my nomination.  Is there a second?  

Now, WHAT we are building, THAT is more in line with distributions (rather than build environments), so long as we are building end user, workstation (read that window managed) applications.  Like a desktop, or even something like kodi, or retropi.  Those are distributions, because they have working end user applications, and are pretty much finished products.

So how does all of that relate to this topic?  Simple.  Our build environments need to provide the tools most useful to the users who are building pine64 products.  What we need is a consequence of what we are doing with the technology.  Legacy has nothing to do with the merit of a tool, only the merit of the tool to do the work that we are doing matters.  That's the relevance.  And let's not forget that many of our participants are new to this stuff, and we get to bring them in.


David

[clarkss12]

Very eloquent, but no idea what you said.  I am almost 69, but you must be older.

[mkrupczak]

Have any of you fine folks gotten Emacs working on the Pinebook Pro? The terminal version works fine, but the GUI one crashes for me on startup.

I'm very disappointed right now, as this is half of the reason I wanted to use this laptop [to run the Emacs "Operating System" ]