OSDev.org

Clearly, your everyday user would see a CLI as making your OS practically unusable if that was the only interface it supported. But for you power users out there, are CLI's sufficient for your needs and do you think that a viable modern OS could be built that doesn't feature a GUI-based shell?

I can't see an OS that doesn't feature graphics gaining much success (other than purely to control a server).

I wouldn't call command line interfaces obsolete, but for any OS with some viable use (i.e. not purely a Server), a GUI is absolutely necessary, for one simple reason: the browser you are looking at right now (not that any OS on here has that, but that's just the biggest dealbreaker for hobby OS usage IMO). People can't live without the internet now, and power users aren't different in that regard.

Don't try to convince me of using CLI-based browsers, they can't even deal with most websites.

This ignores the need for other things we take for granted, like PDF viewers (doable for a hobby OS), image viewers (again, feasible for some of us), etc. but this can, with some effort, be ported to a hobby OS.

Just because an OS doesn't feature a GUI-based shell doesn't mean that it can't run programs that feature a GUI, so the CLI-based OS in question would still be perfectly capable of running any program, such as Firefox. What I'm essentially asking is whether or not it would be desirable/beneficial to use an operating system that uses a CLI to launch programs and other OS services instead of a desktop environment with menus, icons, etc.

But without a gui you could only display one program at a time - totally useless.

If you've gone to all the work of implementing graphics why not implement a gui too?

That would depend on the design of CLI. For instance, it could be designed so that there is a control key that you can use to switch between active programs, and programs could be invoked with arguments that specify how big the window area is and where they are located on screen. That would allow the user to view multiple programs simultaneously and customize how they are displayed. This could of course be automated with a script, so if you have a particular set-up you like, you would just save the commands to a script and invoke it from the CLI. Not having a graphical shell doesn't preclude the OS from having a display server that's capable of managing a basic window rectangle list and compositing them.

Sounds just like a GUI to me!

This sounds an awful lot like i3 or sway (if you're into Wayland), but this still is a GUI in my book.

This here is Vim on top and top on the bottom. (See what I did there? Top? Bottom? )

Actually, it's a split-screen Vim with the bottom window running top.

Actually, it's a Vim running on a Raspberry Pi over an SSH connection from a Linux server running over an SSH connection from a Windows desktop... anyway, having multiple apps running and on display is no problem even in a no-GUI environment.



As for "obsolete"... I consider it a significant win that I can use text-only connections to remote machines this way. I can remote-access systems in my home network from my smartphone. All I need is some "obsolete" tools -- a terminal app running a bash shell and a ssh client. And by accessing "obsolete" tools on the remote machine (like Vim, CMake and GCC), I can continue development / administrative work I left unfinished at home, while on travels.

I know that a slick-looking GUI has much more appeal, visually. But when you start calling stuff that worked well for decades "obsolete", I'll ask what kind of replacement you have to offer to do the same kind of things I've done before. Not in an utopia where everything is running your OS, but in the real, heterogeneous IT world of today.

----

My personal favorite in this (as in many other things) was AmigaOS. It integrated GUI and CLI with each other, while preferring neither. Interfacing GUI apps from the command line was commonplace, and actively encouraged. Using scripts to expand GUI capabilities was likewise encouraged. (ARexx Ports allowed "piping" GUI apps together just like you would pipe commands together on a Unix box.)

I think both GUI and CLI have their place in computing, today and tomorrow. GUIs are something the casual user expects, especially with the prevalence of hand-held touchscreen devices. Command line and scripting is, and will remain to be, the tool of choice for the power user. Making both talk to each other right from the beginning would make any OS stronger, and avoid the harsh disconnect felt when tossed from one "world" to the other.

----

As for, "if I had to choose one" (from the OP: "...if this was the only interface supported..."), I'd choose a text interface over a GUI one anytime. Text interfaces depend on much less OS infrastructure. Text works in "recovery mode" when gfx drivers malfunctioned or the whole GUI infrastructure doesn't "click". Text interfaces are more flexible when doing remote access, can give log output not usually available from GUIs, and generally are more useful in "emergency" situations. This, of course, is coming from an old-school desktop poweruser who is "in the shell" 90% of the time anyway...

---

I'd also like to add that there are / have been solutions to run text based apps with graphical output (like e.g. running videos from a console-interface). They are a rarity today, because mainstream OS' provide full-fledged GUIs. But for completeness' sake, it should be noted that "no GUI" does not equate to "no graphics".

I can reverse the question and state that an operating system that only supported a GUI and did not support CLI would not be enough for my needs. I like to be able to batch process and I still prefer to enter commands at a command line rather than picking an application from a menu. When I run a window manager in Linux, I typically have several terminal sessions open in different windows and probably one GUI application like a favorite text editor or a browser. I think I could get by without the GUI if I need to, but I don't think I could manage without a command line.

I don't know of a lot of Linux systems that are strictly CLI-only other than systems used for repairs like GRML or systems used for learning like INX. However, that doesn't mean they don't have their uses. Also, think about systems for a visually impaired user. Many of the benefits of a well-designed GUI would be lost in that situation. If we're talking about a modern OS, I'd love to see more integration of text-to-speech and speech-to-text as interfaces. That could make a graphics interface unnecessary in some cases. There are some usable libraries for text-to-speech (like espeak and flite). However, I'm having lots of trouble finding a decent speech-to-text library. There are some good ones out there today, but most are designed to send sound clips over the Internet and analyze what's being said on servers. From a security standpoint, it's not a solution I particularly like. Local library options don't do as good a job with speech analysis. I've looked at CMUsphinx and that would probably be the easiest route to go. However, infrastructure for recording the speech would be needed. They have the functionality for some of the major operating systems, but even with a system like Android, there's no support for it in their C library. You need to use their Java code which is a different project. I also looked at Kaldi. It seemed promising. However, it's not easy to get all the dependencies in place just to compile it. I would love to see a decent speech-to-text solution with minimal dependencies that didn't require Internet access just to work. I think that could potentially open up a lot of interesting new areas in user interface design.

My personal preference would be to run applications via a command line instead of a GUI. (I'm sure there are other users that would not have that preference though.) If a graphical programs from a command line is an option, you can run a graphical program that can be used as a menu if needed. Am experimenting with a program that could be used to launch other programs. It currently works in text mode, but I'm adding graphics features so you could potentially display a group of icons and let the user click on the icon of something he/she wants to run or hit an appropriate key and the application would run. Even operating systems that don't support threading, multi-tasking and forks (like DOS) can handle spawning/executing other applications and returning to the original application when the process completes.

If something like Linux framebuffer is an option, there are some interesting examples of operating systems that don't require X Windows or Wayland. NanoLinux and Rogue Class Linux come to mind. Syllable Desktop also lacked X Windows but was able to run SDL based graphical applications. While most browser implementations are not sufficient these days to replace some of the modern browsers (even older versions of those browsers aren't sufficient in some cases), solutions like the links program provide a way to view graphics from a console program. The developer of NanoLinux created a webkit based browser that will run in framebuffer mode. The wkccc library part of it can be used without a GUI or can be integrated with GUI/screen library choices like SDL and FLTK or other options. (Both SDL and FLTK can be run in framebuffer mode without X Windows or Wayland.) I've seen some popular video programs that use SDL via framebuffer. There are also some more extreme solutions like aalib and libcaca.

CUI-only is not obsolete, has its niche uses, but is insufficient for almost all of your potential users. Unless you dream to cut off 99% of them, you want to have a GUI system. needless to say, any GUI system is able to provide CUI.

...if the GUI actually gets to run.

Yes, I know, early-boot diagnostics and recovery is one of the "niche uses" you are referring to. I just wanted to point out that there are very few systems where the GUI is "native" to the system (Amiga springs to mind), and that for the vast majority of systems, there's a text mode in the boot sequence before there is a GUI mode. If you rely on the GUI for everything, once your system fails to boot properly, you're bricked / stuck.

Hi,

I think Solar made a perfect argument for CLI. It's always better to use command line remotely than messing around with X11 forwards or RDP.
And also you can work a LOT faster in CLI than in any GUI, simply because you have a command history and shortcuts, plus with one command you can do something at once that would require dozens of clicks on different windows. Also it's easy to put commands in a batch file, while I haven't seen any good solution for batching GUI operations (anyone used MacOSX Automator? Just terrible, and that's the best tool I've seen so far.) So I'm sure too CLI will never be obsoleted.

Just an interesting fact, even Windows is moving forward CLI from GUI more and more with every release. Just think about how much CLI support Win Vista had, and how much more Win 7 had (think about the additions of netshell, powershell, diskpart etc. etc. etc.). And now they have rewritten the terminal application for Win 10. I really doubt they would do that if there wasn't a real need and pressure from the users.

Cheers,
bzt

That's obviously true.

But if you rely upon the CLI for everything you are going to have a pretty tough time navigating the simplest web site. I'd venture to say that that is one of the commonest uses of modern OSs.

There is something of a difference between the subject heading of the OP (Are CLIs obsolete?) and the body of the post (could you manage with a non-GUI OS?) The answer to both questions, for the vast majority of people is "No". Some posts here concentrate on the first question, others on the second. The big advantage of a GUI OS is that they include a CLI interface.