Bye Bye Vi: GNU/Linux Distros Drop Support

If you grew up with Unix systems like we did, you’ll be sorry to hear the news: vi, the noble text editor that has served us so well these 40 years, is going away — from many GNU/Linux systems, anyway. As of this writing, GNU/Linux Mint, Debian, Ubuntu, and OpenSUSE — four of the five most popular GNU/Linux distributions — have all announced that they will no longer ship the ‘vi’ editor as part of their base installs. For those of us who got our start in the punched-card era and still think of files as a collection of lines instead of a stream of bytes, this is a major blow. But, we can all take some comfort in the fact that, at least for now, the stripped-down version of vim synonymous with vi on these systems will continue to be available from package repositories.

The reasons for the move aren’t entirely clear to us, but from what we can see on the GNU/Linux mailing lists, the confusing modal interface and the fact that novice (and many seasoned) users can’t figure out how to save a file and exit the program seem to have influenced the decision. Also cited were support changes expected as GNU/Linux gains in popularity. As the user base expands to include less technically-savvy individuals, fewer people will be able to fix their constant boot issues, which is the primary use-case for vi. Replacing the self-help model will be a support infrastructure where users can take their machines to “GNU/Linux Geniuses” who will solve the problems for them.

The War is Over

This move essentially puts an end to the editor war between vi and GNU Emacs, a conflict which has continued since the mid-1980s. GNU Emacs isn’t installed as part of the base for most (any?) distros either, so the announcement puts the editors back on an equal footing, at least as far as distribution goes. To obtain a version of vi on your favorite Linux system, you’ll need to install it explicitly, like GNU Emacs users have been doing (and whining about) seemingly forever. We don’t expect hostilities between the two camps to completely subside, but we can’t help but wonder if the energy would be better applied elsewhere, considering the replacement editor that’s slated to be shipped instead.

Out With the Old, in With the New

So, with the two favorites out of the race, what will be the default editor in the new GNU/Linuxes? We spoke with an insider at a major commercial distribution (you know which one) who told us that a version of Microsoft’s Visual Studio Code (renamed GNU/Visual Studio Code) will ship with the base install of all future versions of their GNU/Linux operating system, effectively replacing vi. While we were initially surprised by this decision, the reasons quoted make a lot of sense. First, there’s popularity. Visual Studio Code was ranked number one in the 2018 Stack OverFlow Developer Survey, with 34.9% of over 100,000 respondents saying they used the editor. Vim users represented only 25.8%, with Emacs at a tiny 4.1%. That many JavaScript developers can’t be wrong.

Our source also cited Microsoft’s recent forays into open-source, including the GNU/Visual Studio Code editor itself (released under the MIT license), the groundbreaking release of Windows calculator code, and their recent purchase of GitHub:

So far, Microsoft has embraced open source, and continue to extend the projects they’ve become involved with. I can’t wait to see what comes next.

We agree.

167 thoughts on “Bye Bye Vi: GNU/Linux Distros Drop Support

    1. Hey now. This post was supposed to be a joke. What you are saying is too close to the truth.

      Remember, the “war” can only be fought over that which can be influenced. New users usually end up on nano. Vi and Emacs users are pretty well set in their ways. The other side “winning” the war wouldn’t pull them away!

        1. Why, pray, would you think that systemd would allow you to edit files at the command line?

          This is a cancer that is now even ruining resolv.conf configurations, something that even network-manager didn’t and doesn’t do.

      1. Yeah as someone who started tinkering with Linux about a decade ago. I tried Vi and Emacs before finding nano.

        Nano was by far the easiest to use so you can guess what I stuck with! It just works and doesn’t require a large learning curve or to have a big cheat sheet handy to use it.

    2. It sure did, for crappy text-only editors – IMO deservedly. If I’ve got a GUI, I use gedit or sublime text – both of which you have to put in yourself, which is not a big deal. I’ve even been known to install VNC in headless target machines just for my convenience. Efficiency isn’t that big a deal at my typing speed of only a little over 100 wpm.

      I use gedit instead of leafpad, xed, pluma – whatever the F some new intern has been tasked with messing up for each new distro because…it’s mature, no one is working on it anymore – to some a death sentence, to me, a chance to just get on with my work without surprises and having to remember N names for the something almost entirely unlike the same old thing.
      I never did get what was wrong with things just doing one job well and simply working.

      1. That’s something I like about Emacs. In gui mode it has clickable menus, uses the desktop manager’s file interface for opening and can copy/cut/paste or have it’s cursor positioned using the mouse. And yet, open it from a text terminal (such as ssh) and it’s still the same program!

        Nothing else I know can touch that.

        1. WordPerfect for DOS 5.1, well into the Windows era. That’s what brought me to linux, not any programming, networking or other advanced tech need. Never had skin in the “emacs vs. vi” wars. I gave up on Word for Windows and Microsoft all together and I ended up following Hackaday from there!

          1. It’s funny the paths we take. I made my first syntax error on an Apple ][ back in 1983 or so. I enjoyed that green blinking cursor until I got an Apple ][gs and then Macintoshes but got tired of wasting so much money on software/hardware that wasn’t supported well and not so commonly used. I eventualy went the way of PCs and Windows even though I had been dablingin DOS since its inception. I even became an MCSE/MCSD and even an MCT, then my employer closed up shop and so did the market and I ran towards Linux full speed. If it wasn’t for my kid’s interest in playing games I’d stay away from Microsoft all togther but that policy has never been practical. Now I use linux by default and other operating systems only when the context demands it. I like to use nano to edit text files, but often use gedit when there’s a lot of cutting and pasting to do….so I’m back at looking at green text in a black background at the command line again and it feels like home. …..fajearaf[enter]….command not found…..not quite the same as “syntax error” but good enough, especially in the rich glow of cool-retro-term. I’m back home again. :-)

      1. If VI is the only thing installed I can get by in a pinch…but much prefer pico/nano. Vi is like what was built into the coco computer..it works but not very efficient

        1. imho the exact oposite is true, i mean, vi is too efficient for normal user, its predecessors were working even on computers without displays – the output was only printed on paper. So that style of editing is efficient in a way that a few keystrokes have effect as whole gui with clicking menus.

          The bad side of it is the impossible learning curve. So that is why everybody prefers gui editors (i am talking about text input not the IDE features).
          I am not saying vim is for everyone. The other way around.
          Tho imho, if you plan to make money through keyboard for the rest of your days, vim is a proper place to invest your time to, much more than eg typing with 10 fingers. Cuz it takes time, but in the end you just type + edit faster wiht “less keystrokes”, than in any gui editor – you don’t get your fingers off keyboard to mouse, and that is faster. You slide down from the other side of the steep learning curve, like in winter on sleds.
          ascii potato= ()

          1. “impossible learning curve” – hm, for a moment I thought you must be talking about emacs. I remember in grad school working on a remote machine that didn’t have emacs. A couple of classmates were complaining about how inefficient VI was, so I looked at what they were doing. Yup, using ten keystrokes to do what I could in two. Neither emacs nor vi nor anything else is inherently better. It’s what your used to, what you’ve used for so long that you no longer have to think about they keystrokes. Then something happens, case in point, was in an accident, got a cast, and could only type with two fingers on my right hand (I’m mostly a touch typist). I kept having to stop and remember what the keystrokes were because they were in the fingers that I couldn’t use.

          2. In other editors, if you are being efficient, you don’t use the mouse either. You either remember shortcuts, or you pull up menus with Alt+first letter, and select items by letter or arrow key.

            Though, I have recently noticed that many young people don’t use the keyboard enough when editing text in wordprocessors. They don’t use ctrl-arrows to move by words, home and end to move to the beginnig or end of the line, or shift- (or shift-ctrl-) arrows to select. They just inefficiently aim with a mouse.

          3. The blame isn’t just on the young users who use the mouse way too much. It also rests on programmers who make interfaces that are point-and-clik only. Users who use lots of different apps can’t automatically expect for even basic key commands like ctrl-x, ctrl-v and even ctrl-q to work. Then there is a matter of consistency between operating systems as well as apps. I have to hit alt-fx to kill firefox in Windows but it’s ctrl-q in lxqt-linux. With all this inconsistency, people get learning-chain overload and just give up and point-and-click, effectively avoiding the more efficient methods.

          4. My boss from way back at the start of my career was a vi god. He could move around, searching, replacing, cutting and pasting, etc. so fast I couldn’t even follow the screen (and way faster than anyone I’ve seen recently with a GUI editor). I used MicroEmacs back then and was pretty good with it. I never quite made the switch to full GNU Emacs. Somewhere along the way I switched to vi and use it today, mainly because I can always depend on it being present on any *nix box I use. But I’m not very proficient with it.

        2. I’m best with emacs but that’s because I started using because I liked the idea of it being a lisp interpreter.

          Not that I ever really learnt lisp to see any benefit…

      2. Forced to use vi… ok let me put on my old man suite now.

        Way back in times best forgotten when internet access came in on a telephone line I first started using Linux. The best way to get it was to buy a book from a book store which came with a CD-ROM inside. I think mine was RedHat 1 dot something or other.

        Anyway, this was also before Lennert Poetering’s idealogical granddaddies started trying to “standardize” linux distributions so vi was not yet THE standard pre-installed text editor. Most distros (or at least those that I tried) came with both vi and Emacs, the big slogan back then for Linux had something to do with choice. Hmm, imagine that, how quaint.

        Anyway, also not standardized back then for reasons that I do not want to even try to understand was the escape code that represented the backspace key. Even between two minor revisions of the same distro it might be one of two values. It was ridiculous! (if you ever wonder what that was like go check out BSD, they STILL haven’t agree on a backspace code yet!)

        Anyway, as a result of this in some installation environments backspace worked in Vi, but in most it worked in Emacs. It rarely worked in both. Now sure, there are other key-combinations that get you backspace. But that meant reading TFM and how many people who are already reading a gazillion FMs in order to learn to install a now archaic Linux (it used to be much harder) are going to want to study up on how to do a simple think like run a F’ng text editor? Really?!?!

        And do you know how annoying it is to almost finish editing that 15th GD text file that you need to fix so you can get the network up and install a more reasonable text editor to edit the remaining 155 files but accidentally press one wrong key and not have any backspace?

        So, anyway, yeah, neither Vi or Emacs was ideal but since Emacs was more likely to have a working backspace that meant it was first priority to learn. Once it was learned what was the point of Vi? Oh, then some DB decided Vi should be THE standard.

        I fully support Pico or Nano as THE standard. It may be rather Fisher Price but it’s small, easy and it will do plenty good enough to edit your configs and get you to the point where you can then download Emacs. (or Vi if you like abusing small animals)

        1. Well at least in VI you could always press escape, go to the character with hjkl and delete it with ‘x’. You have other options if you don’t have backspace. Not sure if this is the case in Emacs too.

          And a big benefit of VI is its tiny size and yet powerful commandset. Makes it very useful in bootimages.

          1. I don’t think you understand the times that Jay was talking about. For a new user finding those key combinations would have meant reading the man page or maybe TLDP project. Neither would make it easy. There was no summary telling one the important things that a beginner needs to know. They were basically alphabetized list of every command, every option, and every key combination with no indication whatsoever of what is an important daily-use feature and what is minutia that only a small handful of experts might use once in a blue moon. RTFM in those days wasn’t telling someone they should make a reasonable effort to find an answer before asking a question. It was telling them that they should spend days studying a dry document that tells them mostly stuff they will never need to know.

            On top of this the installation process for Linux itself was very different from today. Pretty much everything was done manually. One even had to run mknod manually to create the node files as udev was hardly even a gleam in a programmer’s eyes. This meant there were many of those man files to read for things that actually made sense to be complicated. Who wanted to go through that one more time just to learn how to do a simple thing like change a couple values written in a text file and save it? Why should something that would be so simple in any other OS be so hard?

            And backspace? The keyboard has a button for that! However many clever multi-key bindings might exist what excuse is there for an OS to not process the backspace key right? That’s almost as bad as if one of the letter keys didn’t work so to type you you had to learn to type Ctrl + some other letter.

            Anyway, for me the editor that got me through the beginning was the one built into mc (midnight commander). It used the F1-12 keys and had a menu bar so you could just look at it to know which keys to press to do the common important things.

            Of course I didn’t stick with mc. Eventually I learned “real” text editors. That came after actually getting the OS going though. A person can’t learn everything at once! That was especially true in those days. Today you just google Emacs or Vi + Tutorial and chose from any one of a number of pages where someone starts you out with a sensible subset of commands and key combinations to get you started. You don’t have to start by drinking from the manpage firehose.

        2. vi is that archaic monstrosity I’ve accidentally used a few times because I forgot to install vim on a new server.

          I use emacs for code, and vim for editing config files. The only important things to remember are: control-q for XON after accidentally pressing control-s (XOFF), and press escape three times to exit the emacs minibuffer input.

          PICO should definitely be the default. It should not be any surprise that a text-mode email program has the best default text editor. It seems rather obvious that people who could survive a mode-based text editor would have intentionally installed vim in the first place. There is no need for vi anymore. And people who don’t know how to install packages don’t want emacs at all, any version.

          In the olden days, linux admins needed vi so that they could set up networking before installing everything else. These days networking hardware is auto-detected and usually starts up in a working condition.

        3. vi came with AT&T System V, AIX, SCO, and Data General. I learned it to be able to work no matter what box I was talking to. I use other editors too, but when I’m already at the command line, and know what I need, vi will get it done quicker than I can reach for my mouse.

        4. I got one of those RedHat books which had a guaranteed lifetime subscription to RH Linux. I keep hoping I find my old copy, email a scan and see if they would honor it for RHEL. Probably not, but a fun little prank, anyways.

        5. I make it real easy for our team:

          Thou shalt use vi/vim.
          Thou shalt not install or use emacs, ever.
          Nano/pico is always uninstalled during provisioning. Thou shalt not re-install.
          Thou shalt not install a GUI on any server.
          Thou shalt not complain about or work-around these commandments, or thou shalt not work here.
          These commandments ensure only skilled veterans ever touch our GNU/Linux servers.

          There. Problem solved.

      3. I have, on rare occasion found myself dumped into NANO instead of a more useful editor such as VI or EMACS.

        I found the experiences in question most distasteful and could not wait to leave. Unfortunately, none of the standard methods of exit worked: ^C, ^\, ZZ, etc. I finally had to d a web search to figure out how to leave that horrible place.

        Turns out that leaving NANO uses the same command as saving buffers in EMACS… ^X.

        VI (technically VIM) is wonderfully efficient — Far more so than NANO/PICO in my experience. I love its syntax highlighting capabilities, the ease with which one can yank and put text, the fluid integration of regular expressions for search and replace, the ability to execute commands against ranges of text specified either by address or by regex, etc.

        VI is like flying a Mooney whereas being stuck in NANO reminds me of being a passenger in the baggage compartment of a Piper Tomahawk.

      1. jupp or jstar (both forks of joe) are easier to use without a manual than nano/pico. Industry standard WordStar keys, built-in help, good syntax highlighting, very small. The keyboard commands in nano are just plain weird, and make even less sense than vi.

    3. A moron who has no idea how to type :w to write out the file, and :q to quit has no business editing at a shell prompt in the first place. I’d like to see the bright idiots who made this decision figure out how to click on their pull down menus on systems with no mice, or a system with an inoperative mouse that the USB mouse driver never loaded.

      What this really means is that we’re all back to hoping ed is installed and using “ed”. Fuckers.

      1. Just one gripe with :w… If a file is not writable by me, it doesn’t come up with a prompt to ask me to give the credentials of a user who can (like root). Wish they had added that. But I guess it’s not possible to change a running processes’ authuser. A process runs as the user that it was started with.

        Something that I DID like with Microsoft Windows. Just authenticate with a new user/pass, and use the new DACL to write the file after all.

          1. TECO was certainly the inspiration, if not the direct ancestor, of vi. Legend had it that people used to dare each other to type their names into TECO.

          2. I was greatly disappointed to see how line oriented vi was on a “bag of bytes” file system. If I forgot to type ESC before CR, I couldn’t backspace over it. It’s one reason I use emacs.

            Ric: back up one character and insert “c”.
            Eric: open file “ic” for reading.

    1. When Ted pitched this article I also took it hook-line-and-sinker. My mind immediately jumped to “how is it possible, that’s a core utility since forever?”. I think his pivot to talk about the replacement software is pure genius. Well done Ted, I had a great laugh over this one!

    2. I’m ashamed to admit how long it took me to realize what this article was… It was your comment that made me realize it which was met with a simultaneous “god damn I’m and idiot” and “thank god!”

    1. Ditto. Got me riled up for sure for a minute. I mean, I’ve seen some Linux distros take some pretty radical shifts recently and ditching vi/vim for the sake of some crazy ideal would be altogether unsurprising.

  1. Its too bad this is a joke. of all the software i have used over my 30 years. I can say without a doubt that VI has been the worst and most aggravating one to have ever used. Only people who are masochist love it.

    1. Anybody who thinks vim is junk just hasn’t tried to understand it. I’m an emacs guy, but when I grokked how vi worked, I could understand completely how people would use nothing else for serious text editing.

      1. The big problem is, that those people often do not want to try to understand it. But it is their problem, if you want to edit file anywhere learn vi/vim. If you do not need to, don’t learn it and spend another 30 years being aggravating by something you do not understand.
        Life is about trying to understand stuff and then seeing if that stuff works for me, or if i should ditch it. Tho understanding before ditching is “my #1 rule” for life.

      2. I don’t think it’s junk, but I do think it’s a pretty good analogue to Linux generally – utterly obtuse unless and until you invest far more time and effort learning it than can be justified to accomplish 99.99% of one’s text editing needs. That, in itself is perfectly fine, but where it gets ridiculous is when those who “grok” it belittle a new or average user for getting frustrated when they just need to make a little edit to a dang conf. file.

        1. vi is for editing on a system where you can’t afford the resources to install emacs, or you can’t afford the memory impact to run emacs, or you can’t afford the bandwidth to paint an emacs screen. As such, it’s perfect for your rsh sessions running over your V.32bis dialup line.

          For new users, it’s less of a tool and more of a honeypot.

    1. Same here. Right up until I hit “GNU/Visual Studio Code” like a pothole in an otherwise perfect road.

      If not for that last paragraph, I would have been shocked to find vi on my next Linux box.

    1. No, but I do recall logging in to another terminal—old lab, olden days, just dumb terminals—and typing “kill “. (c:

      I also recall becoming a lab assistant later on in that same lab and getting confused, at first, when someone asked, “How do I get out of this beep mode?”

        1. Ha!

          BTW, way back when someone, I think it was on some vi USENET group, had the vi reference coffee mug made up. It’s very similar (identical?) to this one. I ordered a bunch as a group buy, kept one, distributed some to the group, and ended up with half a dozen extra or so. Gave them away to someone whom I’ve never met who worked in another office (w/in the company) in another state. Never even gotten a simple thank you note. Should’ve kept the lot. )c:

    2. I’ll admit having to reboot my system while using vi, but I have never had to reboot my system BECAUSE of vi. I think your implication is misleading and just needed a simple rebuke.

  2. vi will never go away. While the core of vim may be stable and only receive minor tweaks, there are always constant add-ons and syntax support being developed on a daily basis. I use vi for python development with all the additional support tools and it is just as good as any IDE out there.

    Same for other popular languages, including some that those numerous JavaScript developers might be interested in :)

  3. Anyone that says they’ve NEVER had to reboot to exit vi is probably lying… Sure, you know you did it when first learning vi, dont lie! That still counts! Nothing to be ashamed of, for Pete’s sake!

    I use nano now. Well, since 1999, to be exact.
    I’m an old timer…. Used most of the UNIX variants; Solaris, AIX, SCO, IRIX and the BSDs. STILL hate vi.
    If I’m doing an Arch install (my daily driver), when I’m editing my sudoers file, it’s always EDITOR=nano visudo to drop me into the sudoers file.

    I am not ashamed.

    1. Well.. to each their own. I never understood why people bother appending EDITOR=…. to their commands though. I just set EDITOR=emacs in my ~/.bashrc and forget it!

    2. I don’t remember ever having to reboot to exit vi(m), and I’m not lying. OTOH, I’ve been using BYOBU for years, and if I did have vim freeze up, I’d just CtrlA C to get a new terminal and kill vim from there.

      I think I learned vi back in the late 80’s when work got some NCR towers. At the same time, I started using a DOS vi clone called Elvis so work and home editing was equivalent. I soon developed enough vi finger memory that it’s reflexive anymore.

      Nowadays, the first thing I do when I install a new Ubuntu server is to ‘sudo update-alternatives –config editor’, and set vim to be the default editor.

  4. Microsoft got where they are through deception and piracy. Now they’re in it for the data mining. I’m certain you will be able to get Vi somewhere else after all I have it on win10. Beware of april 1 though, but BASHing macrobloat is always fun. You’d better have at least 8G ram in your windows box or you’ll have to restart every 25 minutes instead of hourly due to the slowdown. You can probably get coffee and a sandwich in Singapore while waiting for all of MSVstudio to load unless the airline terminals are running windose. Fret not, they also sell their framework to other folks so their software can be as bad as MicroSodt’s.

  5. The only reason I EVER used vi was because that was the standard editor that came with ALL versions of Unix or other-ix. But news flash, EMACS is like learning Chinese just so you can read the instructions for devices that don’t need instructions.
    In other words, in the battle between vi and EMACS, BOTH are losers. Today I use vi only if I’m already working in a terminal and need to do something simple, and can’t be bothered to open a bit, fat GUI editor. I never have any reason to open EMACS.

  6. I see google news picked this article up. Wonder how many normal people will think this story is factual.

    BTW, I agree with you about emacs. Yech with a big capitol Y. i can deal with vi. Not the best but after 30+ years, you get used to it.

  7. I know this is a joke, but… I use vi myself, but only after first installing vim. For some reason, until I do that, certain keys do not work properly. Once I install vim, vi works like I’d expect it to. To be honest, I have been doing this for so long,m that I have forgotten exactly what doesn’t work, but I know that I tried on multiple systems over the years and installing vim was the only way to get it to work “right.”

    1. Arrow/cursor keys while in edit mode are broken in basic vi on Debian/Ubuntu. One has to escape into command mode to move a line up or down.

      This being broken since at least ten years is a story in its own. Hundreds of thousands of users out there, but nobody taking these couple of hours to get it fixed :-)

      1. vi doesn’t need to be “fixed”; it is not broken. vi was written in a time before terminals had standardized what codes the arrow keys generated, so it used alphabetic characters for cursor control. All Linux installations include vi, but many do not by default install vim. If you want to use vi in a modern environment, and have the non-ASCII arrow keys work as you expect, you probably want to use vim instead. This is an extension of vi that addresses modern expectations of keyboards. But if you don’t mind using h, j, k, and l for cursor navigation, vi still works.

  8. The Midnight Commander, a spiritual descendant of the old Norton Commander from DOS days, has a wonderful internal editor called, with all due respect to the hamburger chain, Mcedit. I’ve used it for years on the Linux console, because the MC does such a stellar job of making filesystems (including windoze) understandable in a very visual way.

    1. When I encountered them in the late 80’s, it was perfectly plausible to have access to machines which couldn’t run emacs very well without hardware upgrades, and thus it wasn’t installed.

      And installing it meant letting things compile overnight, and that assumes you didn’t have to first build a new gcc.

  9. I’m gonna put my REAL OLD man hat on.

    I started on *nix-style systems back in the System III days (last century, kids, early ’80s) on a Charles River Data Systems 68000 box running UNOS (CRDS’ version of System III). I had to learn vi just to work on the thing. From there I went to a Fortune 32:16 (another 68000 system) running a more “stock” version of System III Unix. Next box was an AT&T 3B2 – the reference machine for Unix System V. Used Xenix, Interactive Unix System V, and SCO Unix after that for the medical office billing software we were writing.

    Most of the Linux distros that came after that had utilities based on what was available on the 3B2, and that included vi.

    My programming partner and I built up a library of vi macros and had a primitive IDE that would lint a pile of C code, compile it with and without debug, and run a make file to rebuild the program we were working on, all in a few keystrokes.

    I don’t use vi much anymore, but when I do, it’s pretty much like riding a bicycle. I really like VIM, with its color-coded language specific presentation.

    Oh yeah, Happy April Fools day!

  10. I really really like nano. I’m completely fine with this. Every time I tried to use vi, I was completely confused. I mean it’s 2019, current year and even servers come with a small amount of video memory, enough to run a small gui like xfce. It’s not the 80s, 90s, 00’s, and we’re leaving the 20teens. We’ll soon be entering the roaring 20s with swing music, amazing architecture, and the singularity. Things like vi should die.

  11. The title of this article isn’t just misleading clickbait; it’s dead wrong. Dropping support is completely different from just removing a package from the default install.

    This is not a big deal. Few people will even notice, and they’ll just install it and carry on.

    Honestly I expect better from hackaday. You have good articles. You don’t need clickbait titles.

  12. As Mork from Ork would put it, “nano nano”
    [ New File ] ….hmmmmm … ctrl-x …. ah the command prompt is back. Some day it will only be gedit or leafpad. I’m not looking forward to that day. I love the green glow of the phosphor in crts, fake or otherwise. I can’t stand the glaring white of gedit or any of those wordprocessor-like text editors. Why so much whiteness man? Are you wishing you were commander Cisco talking with the prophets that live in the wormhole between the alpha and delta quadrants? (I think its delta and not gamma and there seems to be some kind of taboo in talking about the beta quadrant) :-)

  13. So… Ubuntu doesn’t ship with vi anymore, but needs cloud-init (and Python) to set the system’s IP address. Got it.
    Problem is, programmers will be programmers, and the Linuxes are so non-command-line-user friendly nowadays. Editing config files in /etc was too simple so they had to muck it up and “abstract it all away.” Yeah, yeah, kubernetes et al. I stand up Linux VMs for fun and profit, every week, and I see what they are getting at if you have to deploy 100 of them… but 2 or 3 at a time, just give me flat files and a SystemV directory structure. Now… there are some lawns you kids will need to get off of. Get!

Leave a Reply to BrightBlueJimCancel reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.