I am keeping all e-mail tied to custom domain. If a provider goes down, I can just move that domain somewhere else. Yes, history will be lost, but new mails will keep arriving.
This isn't feasible for most people though. Hence why this exists. Not sure why that's so hard to understand.
Yes, we could set up our own mail servers, manage DNS meticulously, whatever. Most people don't have the time, and many people don't even use email that much anymore to begin with.
Not sure what the argument is here. Just because they aren't your preference, they don't work at all?
I'm guessing this is common practice, or tooling is available, but could you set up essentially fallback DNS to your own servers in the case of protonmail servers not responding? Should you have some middle server that does smarter routing based on the status of the final server? I guess you're nearly running your own mail server at this point, though.
I am leaning more towards just owning your own domain name, and using that for your e-mail address. I.e. configuring custom domain for e-mail. This way, if your current provider goes down (for the long run), you just go to a different provider, and configure your existing domain name for the e-mail. You don't have to change your e-mail address at all this way!
Yes, you could also run your own mail server, but this is not my point.
I don't understand the people who dislike nano as an editor for the *nix system. After spending in it for like 30 minutes - it becomes an indispensable tool for quickly touching up text files anywhere you go to! No matter where I SSH to (*nix systems) - I always had nano available.
Nano has/had some surprising defaults. Way back when, I was using nano to edit some file or another in /etc. When I wrote it out, it "helpfully" justified all the lines by inserting newlines to make them fit in 80 columns. My mentor looked at me disapprovingly, uninstalled nano, pointed me at `man vim`, and said "you're using this now. Thank me later."
Thank you, mentor.
I don't know if nano still has that as a default on any system that's shipped in the last 20 years, but I always give it the side-eye whenever a system has `EDITOR=nano` set and I run something like `visudo`. Am I about to break the entire system? Probably not, but to be sure I exit nano, configure `EDITOR=vim`, and try again. I know vim won't trick me like that.
Switching to vim because you don't want to press ^L (or set the respective configuration option in .nanorc) to toggle off hardwrapping is a bit overkill though ...
It's not like "out of the box" vim is different in this regard. Half the time spent by a typical vim user with vim is coming up with personalised configurations.
Surely if I said I'm ditching vim for nano because I wanted columns hardwrapped at 80 characters by default you'd look at me funny, right? xD
It was more along the lines of "look, you've outgrown this tool, and it's time for you to move onto something more appropriate to the work you're doing". I'm not going to criticize anyone for using nano to edit the random file here or there (so long as using it doesn't break the file). But honestly, you reach the limits of nano's abilities fairly quickly. As fine as it is for a quick change to a file, Vim and Emacs other programming editors are popular for a reason. I surely wouldn't want to use it to work on large projects with lots of files.
Nano is now the default editor on Fedora since v33.
It makes sense. Modal editors have steep learning curves and were designed for an era of non-GUI interfaces running over teletypes. Everyone today knows how to use arrow keys to move around. Being dumped into vi, how many people will know how to go into the various modes to navigate and edit things?
I run OpenWRT on my router, nano is one of the first packages I install on it.
Probably the elitist guys, the ones that have their identity defined by the editor they use, the language and framework and the Linux distro/DE/OS they use.
Many people just need a tool that does a simple job but does it well, like editing a ini file and adding a line or a word, nano is great for that. (we all know that type of guy that has to tell everyone all the time that he uses Arch and Rust would have fixed everything)
> like editing a ini file and adding a line or a word,
That's precisely the use case that has made me remove nano from every machine I administer since the 90s.
Unless you're really careful to always start nano as "nano -w", its hard word wrapping will introduce line breaks where many configuration file formats (including ini files) don't expect, and it will do so in lines other than the one you're modifying. It's less risky to simply set another editor as the default. (But if you're careful to always use "nano -w", it's a perfectly fine editor.)
I've never seen nano on any popular Linux distro hard-wrap long lines by default. Yes, it's controlled by a setting, and some people turn it on for some reason, but I just confirmed it's off by default (no need for any command-line flag) in both CentOS and Ubuntu. You might have been burned by a setting left behind by someone with a weird taste.
I learned to always, always use -w back around y2k, when my buddy taught me Gentoo. IIRC he had gotten his firewall config messed up at some point, or similar, due to forgetting that.
These days I'm still too scared of accidentally messing something up due to not passing -w, so I just do it. It's in my muscle memory after all so doesn't take much effort.
I pretty much agree and share the love for Nano, but - just as a comment - it happened to me that it wasn't available in some Red Hat servers. Depending on your regular work and the type of servers you SSH into, you could expect Nano to be already installed or not
That's actually the entire reason I learned enough vim to be dangerous, on EL7 and below they did not ship nano in the box and there was a project I was working on where we had a bunch of 5.5 systems that had busted network configs. That was a.. joy, to say the least.
Emacs has had TRAMP[1] (transparently allows you to edit remote files in your local editor using an SSH client) for literally decades now, while SSHFS has been around for nearly as long, and even zeitgeist tools like Visual Studio Code have equivalent TRAMP-like/auto-SSH addons.
The "it's not available on remote machines" line of reasoning hasn't been valid for at least 20 years (age of TRAMP), except for the case where you cannot SSH and have to physically sit at different consoles.
I love Emacs. I love Tramp. I love iTerm + Fish Shell more than eterm, though, so if I'm SSHing into a server it's from a terminal app outside of Emacs. In that situation, I'd rather use vim to make a quick tweak on a file than bounce to Emacs, tramp into the same machine I'm already in, and edit it that way.
I've installed nano on every Linux system I've ever worked on, if it wasn't already there of course. For me, it's so much easier to work with than vim, for changing config files etc.
I only wish line numbers were enabled by default, or at least there was a simple and easily discoverable way to enable them.
I had a co-worker, whom I miss every time Nano comes up. He strongly preferred Nano, but not in an annoying way. He’d go through all our documentation and change ‘vi’ to ‘nano’, just because he could. He reasoned that anyone could use Nano if required, but vi could get a little weird at times.
> No matter where I SSH to (*nix systems)
Nano is also available on Windows!
I have it installed through Scoop and I use it when I SSH to my Windows PC from Termux on Android
------
[1] https://protonstatus.com/