> If you are using their [Nvidia's] driver on any version of UNIX, then you will most likely not be able to switch back and forth between the console and your graphical environment.
This is flatly untrue. I'm running Debian and using the Nvidia drivers with a GTX 1070, and switching to the virtual consoles and back to X has always worked fine. In fact, sometimes I have to switch to the virtual console to rescue my session when light-locker eats itself.
> In fact you often cannot run multiple graphical environments simultaneously either, something that is unheard of in the Windows world, but is a given on UNIX systems.
I haven't ever tried this... it might be true. What I have tried is starting two X sessions on laptops with switchable graphics that can use both at once (so one X session for the integrated GPU, and another one with the nvidia driver for the Nvidia GPU). This works fine.
> The only way to work around these issues is to use either the reverse engineered open source Nvidia driver, or configure X to use the generic VESA driver.
In my experience with several generations of Nvidia cards, the Nouveau driver has always been a slower, buggier, worse experience than nvidia's driver. Look, I want Nvidia to release and upstream their driver source as much as anyone, but in my opinion, the author is overstating their case here, and this weakens other parts of their argument that may have some merit.
In my experience switching only works if you disable the fancy nvidia console driver (that assumes KMS etc.) and use the basic VESA framebuffer driver. The nvidia framebuffer drivers can coexist with nouveau etc. but not with the nvidia binary drivers. That might be what OP is getting at.
(I completely agree that the binary nvidia drivers work a lot better - indeed I find them better than the open-source AMD drivers as well)
IDK but on ArchLinux, with the "nvidia" package installed, I can have multiple ttys, some with X sessions, some with Wayland sessions, some as consoles
Thanks for reading my blog :) There may indeed be quite a few errors in there. I meant no offense to Nvidia users, I just have fairly bad experience with that graphic card and console/desktop work on UNIX systems. By that, I mean, things like BSD's and Solaris. Naturally, Linux is your best bet for driver support.
IMHO this is how computers were meant to be used. The whole desktop environment thing has added too many layers of abstraction from the heart of computing.
I understand why everyone doesn't exclusively use console desktops, but it makes me a little sad to see so few people that do.
I use X but not a desktop environment; I mostly use xterm and the command shell for many things. I do use many of the programs mentioned there, including "mail", "calendar", etc.
Indeed a very interesting read, to be honest I haven't read it all of it but I might when I find some free time. The biggest issue as the author points out is the browser. But you can still have the best of both worlds: run i3 + most of the console tools mentioned by the author. i3 is a fantastic manager and when I see other desktop environments I find them so constrained... Most of the people I'm currently working with are using Windows for web development and I find that so weird, I can't imagine myself going back to pointing and clicking here and there with one hand on the mouse most of the time.
> Most of the people I'm currently working with are using Windows for web development and I find that so weird
It's the most common set up in development in the world, I'd argue.
> I can't imagine myself going back to pointing and clicking here and there with one hand on the mouse most of the time.
Just run your Linux flavour in a VM and use i3 in there.
I do all of my DevOps related work (Python, Go, Terraform, Ansible, YAML, etc.) in a Ubuntu VM just using the default window manager (can't be bothered to change it.)
It's not hard to have your cake and eat it too, in this problem domain :-)
I had to work for a week on my gaming PC and used virtualbox to run Linux in a VM with i3. It was really sad, I hope to never do it again.
No matter what terminal emulator I used, there was too much lag compared to the real thing. I couldn't use kitty/alacritty since there was no hardware accleration. When I'm looking through code in (neo)vim, I normally fold everything and then scroll by holding j/k. I set my repeat delay very low, and my repeat rate extremly high so that I can just quickly scroll through code. This was completely unusuable in a VM. I had to switch to ctrl+f/b/d/u and it drove me nuts.
Maybe there was some way to get better hardware accleration, if I had two graphics card, maybe I could have devoted one to the VM and gotten better performance. Or maybe virtualbox is bad vs vmware or whatever else is out there.
I'm sure if I had to use it long term, I could come up with some usable workflow, but I still think using it natively is a significantly better experience.
Is there too much lag through an SSH connection for you?
I often do things this way. SSH from whatever I'm holding to a more powerful machine with my tools and configs. Then the terminal is on your host, at least.
I've also RDPed into local Windows VMs to get a better experience like working copy/paste. That's the approach Hyper-V took with their enhanced session mode
I'll second this. It was well worth the couple of evenings switching to i3 and getting up and running. Besides no maintenance work, there are three main reasons for me:
1) Most of the default config works well out-of-the-box, and you can tweak away things to your liking. Documentation is short and to-the-point.
2) It's possible to start processes and put windows where they belong at startup, using an extra layout manager. You later can tweak the setup by manual keystrokes according to extra needs and there's always extra workspaces you can move to.
3) By splitting parent container from child container, you can keep a fractal hierarchy of containers for putting/moving windows in. This can be managed by keystrokes according to need, and makes it easy to tab/stack/split windows or change part of workspace layout manually, without windows unexpectedly jumping around too much. Most guides fail to show the advantages of this, and is something most tiling WMs lack or implement poorly. Again you get this by default.
If you haven't seen the work Nick Black is doing with notcurses [0] it's pretty amazing to see what it can do with bitmapped graphics in a modern terminal. Makes me wonder if we're ready for a resurgence of TUIs with full motion graphics.
I've often wondered about taking this one step further: rather than using the terminal to render ersatz graphics, building a plain-text based, conversational operating system. Something like a generalization of ed[0], not just for editing but for doing every other task, but with a more verbose English syntax rather than line noise.
You could even do conversational tree editing, e.g.:
Current node: function definition `fibonacci` with one parameter.
>rt
The return type is `int`.
>body
Current node: an `if` statement.
>condition
The condition is: n <= 2.
>replace <= with <
The condition is: n < 2. No type errors.
>build and test
Build complete. 100% tests pass.
Or something like an interactive fiction/text adventure[1] type thing, where you move through a virtual memory palace by typing e.g. "go east", "go up", and perform operations on data by using verbs like take, search, look up, etc.
What you're describing I wouldn't call a huge amount different from an everyday shell. Maybe a few tweaks here and there, but I'm almost willing to bet you could get there with Bash customizations...
It's a bummer they only barely mention emacs. I'm not really an "emacs guy" (I use vim for all my actual editing) but it has all those tools you'll miss from the GUI desktop environment (PIM, doc writer, spreadsheets etc.) and they're all community maintained so they tend to be pretty sane. For example they mention the unix calendar command but they don't mention that the emacs calendar uses a superset of the syntax (and you can restrict yourself to the classical syntax if you want.)
Yes, you can do virtually everything mentioned in my blog with Emacs, especially since you can run almost any console command in it (also ncurses ones with M-x ansi-term). I deliberatley tried to avoid Emacs so as not to go to far of topic. I am toying with the idea of writing an Emacs Desktop Howto though ;)
25 comments
[ 2.9 ms ] story [ 71.4 ms ] threadThis is flatly untrue. I'm running Debian and using the Nvidia drivers with a GTX 1070, and switching to the virtual consoles and back to X has always worked fine. In fact, sometimes I have to switch to the virtual console to rescue my session when light-locker eats itself.
> In fact you often cannot run multiple graphical environments simultaneously either, something that is unheard of in the Windows world, but is a given on UNIX systems.
I haven't ever tried this... it might be true. What I have tried is starting two X sessions on laptops with switchable graphics that can use both at once (so one X session for the integrated GPU, and another one with the nvidia driver for the Nvidia GPU). This works fine.
> The only way to work around these issues is to use either the reverse engineered open source Nvidia driver, or configure X to use the generic VESA driver.
In my experience with several generations of Nvidia cards, the Nouveau driver has always been a slower, buggier, worse experience than nvidia's driver. Look, I want Nvidia to release and upstream their driver source as much as anyone, but in my opinion, the author is overstating their case here, and this weakens other parts of their argument that may have some merit.
(I completely agree that the binary nvidia drivers work a lot better - indeed I find them better than the open-source AMD drivers as well)
72% have the "linux", 40% have "linux-lts". The first "patched" kernel is at 11% of usage
https://forums.developer.nvidia.com/t/nvidia-devs-any-eta-on...
Interesting. I've always had native resolution on this display in the console, so I never really looked into it. I guess it's an EFI thing?
I understand why everyone doesn't exclusively use console desktops, but it makes me a little sad to see so few people that do.
It's the most common set up in development in the world, I'd argue.
> I can't imagine myself going back to pointing and clicking here and there with one hand on the mouse most of the time.
Just run your Linux flavour in a VM and use i3 in there.
I do all of my DevOps related work (Python, Go, Terraform, Ansible, YAML, etc.) in a Ubuntu VM just using the default window manager (can't be bothered to change it.)
It's not hard to have your cake and eat it too, in this problem domain :-)
happy to show you my set up if you want to jump on Discord? https://discord.gg/MTzBvSS
No matter what terminal emulator I used, there was too much lag compared to the real thing. I couldn't use kitty/alacritty since there was no hardware accleration. When I'm looking through code in (neo)vim, I normally fold everything and then scroll by holding j/k. I set my repeat delay very low, and my repeat rate extremly high so that I can just quickly scroll through code. This was completely unusuable in a VM. I had to switch to ctrl+f/b/d/u and it drove me nuts.
Maybe there was some way to get better hardware accleration, if I had two graphics card, maybe I could have devoted one to the VM and gotten better performance. Or maybe virtualbox is bad vs vmware or whatever else is out there.
I'm sure if I had to use it long term, I could come up with some usable workflow, but I still think using it natively is a significantly better experience.
I often do things this way. SSH from whatever I'm holding to a more powerful machine with my tools and configs. Then the terminal is on your host, at least.
I've also RDPed into local Windows VMs to get a better experience like working copy/paste. That's the approach Hyper-V took with their enhanced session mode
It's been fine for me. I'm not that overly sensitive to millisecond delays in rendering or response times, so it works out fine.
Ryzen 3 9600X, 32GB of RAM, nVidia RTX 2080 Super on a 49" G9 Ultrawide, for reference.
1) Most of the default config works well out-of-the-box, and you can tweak away things to your liking. Documentation is short and to-the-point.
2) It's possible to start processes and put windows where they belong at startup, using an extra layout manager. You later can tweak the setup by manual keystrokes according to extra needs and there's always extra workspaces you can move to.
3) By splitting parent container from child container, you can keep a fractal hierarchy of containers for putting/moving windows in. This can be managed by keystrokes according to need, and makes it easy to tab/stack/split windows or change part of workspace layout manually, without windows unexpectedly jumping around too much. Most guides fail to show the advantages of this, and is something most tiling WMs lack or implement poorly. Again you get this by default.
[0] https://youtu.be/dcjkezf1ARY?t=16
You could even do conversational tree editing, e.g.:
Or something like an interactive fiction/text adventure[1] type thing, where you move through a virtual memory palace by typing e.g. "go east", "go up", and perform operations on data by using verbs like take, search, look up, etc.[0]: https://en.wikipedia.org/wiki/Ed_(text_editor)
[1]: https://en.wikipedia.org/wiki/Interactive_fiction
I initially read this as some kind of successor to a putative System-C. Idiosyncratic orthography doesn't inspire confidence.