This has more-or-less been my setup for over twenty-five years. I've used gentoo and vim that entire time, but have changed desktops a few times (i3 currently, but always something along those lines). All development -- and all writing -- is in terminals.
The difference is that I tend to to work on pretty high-powered machines (not for graphics or gaming, but for audio).
But the main reason I have this set up is that I find the minimalism . . . calming? It's not entirely distraction free, but I just find it easier to work in a kind of low-stimulation environment. I do occasionally work on way less powerful rigs (and way more powerful servers), and it's nice that the basic tools don't change. But ultimately, I think my fondness for this way of working might be aesthetic.
The main reason for me is that terminal programs are just less crappy, because people who develop them try much harder. The terminal itself strikes me as a terrible platform - no text sizes, no fonts, no graphics... People dismiss it as unnecessary bells and whistles but then every other TUI program jumps through ridiculous hoops to reinvent crappy versions of these.
If only the same people developed their programs with the same philosophy (minimal, simple, clean UI and keyboard driven) but in a normal GUI, so that you don't have to abuse Unicode to draw UI and just draw it.
This has been my take on things forever. Power user tools tend to be made as a TUI, which is great in that it lets you work from the framebuffer and over SSH, but it really makes you wonder why we can't have the same conveniences with proper graphics.
I'm in the same boat. I want my computing tools to feel like a musical instrument: stable and predictable, very capable but requires skill and learning to use well, and serves me instead of drawing attention to itself. Let me get into a flow state and focus on the task at hand. Working in a terminal is that.
If UIs are constantly shifting or if there are popups telling you about a "cool" new feature, then that software feels less interested in serving the user and more serving its developers. I don't want the manic Silicon Valley hype-of-the-month when I have other more important things to do than fight with technology that's supposed to be helping me (and me exclusively).
A craftsman becomes a master largely by mastering his tools.
When your tools change every damn week because some faceless soulless middle manager wants a promotion, you can't master the damn tools.
I don't know how anyone is supposed to become a master at programming when the industry standard tooling requires waiting around for tooltips to show up because meaningless icons are "clean"
Not only that, but a master craftsman modifies their tools and builds their own.
But it's not even that tools change every week. When you look at things like VSCode it's hard to make your own. Is hard to shape into an environment for you and instead you should shape to it. I see this in a lot of tools and it's destructive. Everyone is different and there's nothing that can be made for everyone. So a good tool needs to be modifiable, so that people can turn it into the thing that works for them.
It rings true, but on the other end of the fence is management class, who wants and prefers that coders are not craftsmen with custom tooling, but interchangeable gears that can swapped at moments notice. In a sense, they want the same modularity, but at the organization level.
You get what you pay for. Unfortunately it appears many are happy with shit and those that are unhappy are unwilling to pay for more. I'll admit, it can be quite difficult to differentiate shit and quality these days prior to purchase. But at a certain point I think you have to stand up to the management class and take pride in your work. It's their job to manage you but it is also your job to make the best product you can. It's becoming pretty clear a lot of tech has been filled with "yes men" and we're seeing the consequences of this. The bigger problem is that I think a lot of people don't even know they are yes men. Probably doesn't help that we build things that are so technical that the public isn't accurately able to distinguish quality from shit until they are able to feel the two side my side.
I hear ya. In fact, I will go as far as to say that it is only more recent that I call out my direct manager, when what he says something that does not quite make sense ( and it does not help that he keeps changing his mind ) for one reason or another. I think it takes not just experience and confidence, but decent degree of political skills ( and I certainly do lack confidence and political talent ). Not to mention, I distinctly remember feeling ( way back when I first questioned stuff and got punished for it ) that it is just 'easier' to be a 'yes man'.
Yeah, I definitely do not think it is easy, but this is a thing that has been part of (at least) American culture for awhile but it seems we've been losing it. I personally think it is a big part of American success as we all know there are just things you can see "on the ground floor" that are hard to see from higher up. Hell, we even used to have the show Undercover Boss[0] haha. Obviously it is TV but I think anyone can reason through the truth of this.
I'm still working on how to do this right. But I think it is important that all parties recognize the pushback isn't about "us" but since we're on a team trying to make the best business possible. Part of why I struggle with this is 1) I just generally don't care about authority (maybe a bit too autistic lol) and 2) we're all wrong, so being wrong shouldn't really be seen as that bad of a thing. We're talking about pretty complex problems and we're only human with two eyes that must be in the same place at the same time, so it is pretty obvious that we're going to miss some stuff. It's about being less wrong, and if someone is giving you new information from a perspective you don't usually have access to, you sure want to check that it fits your current working model. If not, you're more wrong by not updating.
There's an information asymmetry here that makes things difficult, but a good manager will always listen to their employees BECAUSE they want to better the business. A good culture will allow "arguing" as everyone should be on the same team. As long as the "arguments" can end on good enough terms like everyone is willing to have a beer together at the end of the day. We get heated with our best friends and partners, right? Confrontation isn't destructive, it /can/ be very constructive. But the culture has to be right. Both management and employees need to be happy to share credit when success is made. This is definitely something even low level employees can do to help cultivate these good cultures. Management can do it by not just encouraging this but also watching to make sure it happens and do their best to make sure that success is properly allocated. Otherwise there's a natural incentive for "bad actors" to oversell their possible contributions. That's how you get "Loud Laborers." I think people think just because you're "a small cog in a giant machine" that this means you can have no impact. But the truth is that every cog is critical to the machine. It's just that the small cogs need to align and the problem is that a bad cog can upset the balance of everything. Success is unstable equilibrium.
Totally agree that the constant churn of new tools which come and go makes adapting to them and truly mastering them feel pointless. But there’s also the well established old things which (according to Lindy’s Effect) will be there for a long time still - things like Vim, Emacs, efficiently using shell. Investing time in truly mastering them seems like a good long term bet.
There is definitely value to be had in using systems that force you to write high-performing code. In the web space we all too often we sit down at high powered macs to write code that will be run by low-end Android devices, and fail to appreciate the consequences.
I'm always wondering about thoughts like this. Although there are likely a humongous amounts of low end devices, as a whole, how much potential return would you get from this group? This is a value judgment and I know many have low end devices for reasons other than monetary and just completely ignoring quantity may not be viable for certain investments, its just an interesting thing. It might be similar to the debate about the cost of handling credit cards vs cash. Cash has its own set of costs that are usually neglected. You could easily get more return by adding features than spending any time optimizing.
> how much potential return would you get from this group?
This reads a bit like "these poor sods can't afford to pay for my app, so why bother", at least to me.
However even if a certain device owner subgroup doesn't represent a potential revenue stream, you can as a developer still profit from also (or even primarily) targeting their devices.
Apps that will run on lower-powered devices will almost necessarily be leaner, and as a side benefit will have less complexity, less dependencies, and, ultimately, less technical debt for you as the developer to manage.
Or even just devices in high-latency environments. This gets missed in development so often. My experience is that 75% of apps cannot handle it and fail to work in all kinds of ~~interesting~~ frustrating ways.
I think they mean them, and the obviously-high percentage of developers that use Macs compared to the general population of users. Which, ironically, skews the percentage of Windows users lower than most other demographics.
In fact, how dare you forget the Linux users when writing your comment?!
Faced with the option to pay higher costs for incredibly good hardware, or to run any of the many *nix distros, you chose to have meh hardware, and a restrictive OS that is built as a GUI first, terminal a distant second.
Bash is bash, zsh is zsh; how are they different? coreutils differs, sure, and I dislike BSD’s implementation of them, but that’s why gnu-coreutils exists.
When talking about Linux workflows on older devices it is always worth it to remind people of the existence of kmandla[0] and their later website Inconsolation[1]
> Terminal text editors are also lighter due to the fact that the terminal is providing all of the windowing fuss for them and that terminals are light applications in and of themselves due to not having to do much that is extremely novel or intensive on a CPU
I think this is a common fallacy. Fundamentally adding an tty layer in the middle does not make lighter solution, so in almost all cases terminal application+terminal emulator is inherently heavier than equivalent application talking directly to display server.
I think the performance in terminal apps could come from the fact that terminals can use pre rendered, pre cached in GPU, text glyphs covering a fixed size small grid (of glyph sized blocks instead of pixels.) At least that’s what I have wondered - because the terminal UI experience has been always a lot more slick compared to heavy GUI based programs. Feel free to correct me if someone has done actual performance analysis.
How does that implicit state help with anything if you look at the system as whole? Sure, with terminal applications the costs are spread around in more components, but ultimately the total can not really be smaller. You still have the GUI stack in the end, with terminal apps there is just terminal emulator and tty layer in between.
The terminal layer can exist outside of the GUI. That GUI programs provide emulation for this, yea, adds the whole GUI layer back in so systemically you are worse off.
The application doesn't notice any of this though. So they're easier to develop and the program itself runs faster (is lighter). Which is the specific point the article was making.
VGA cards haven't provided actual 80x25 text mode since forever, so you're still converting to pixels at some layer. Which means you might as well take full advantage of having full control over those pixels, rather than constraining yourself to the patterns that happen to be in your font.
With full control over pixels, you can use any combination of "text" and "graphics" that you want. For example, you could make Vim or EDIT.COM but with a normal mouse cursor and a scrollbar with pixel granularity.
> VGA cards haven't provided actual 80x25 text mode since forever,
Are you sure about that? The memory range still exists and still operates the same as it ever has. The _card_ just does the translation for you.
> so you're still converting to pixels at some layer.
This has /never/ not been true.
> With full control over pixels
Yea, again, you are intentionally not understanding the point the article or myself made. The application in text mode does NOT need to do this work. The application IS lighter as a result.
> but with a normal mouse cursor and a scrollbar with pixel granularity.
And how do you receive mouse inputs? With more code. How do you manage pixels? With more code. Are you understanding that this is PRECISELY the point here?
Generally you're going to need some sort of layer in order to display something meaningful; even if you count ncurses, the tty stuff is way, way lighter than all the rendering code, componentry, and hierarchical dispatch stuff that goes into a typical GUI toolkit. And it can appear on more devices.
> even if you count ncurses, the tty stuff is way, way lighter than all the rendering code, componentry, and hierarchical dispatch stuff that goes into a typical GUI toolkit
But using tty/ncurses does not avoid the costs of GUI, your terminal emulator will still need to have that. So using terminal can only add additional cost, not reduce it.
The costs of, say, xterm (or even konsole) + tty layer are still far less than the costs of the UI layer for a halfway decent IDE. It's a bit penny-wise and pound-foolish to worry about the added cost of the tty layer when the "talking directly to the display server" approach incurs so much more cost, unless you were willing to accept an unusably minimal user interface (worse than any terminal program would be).
Remember, Unix systems implemented tty support in perhaps tens of kilobytes of memory, on CPUs running at single-digit megahertz speeds. Graphical IDEs these days are often frickin' Electron apps.
> when the "talking directly to the display server" approach incurs so much more cost, unless you were willing to accept an unusably minimal user interface (worse than any terminal program would be).
Talking directly to display server simply can not incur more cost than having terminal application and then terminal emulator talking to display server; the talking to display server is something you need anyways, and anything else (like having a tty layer) is just additional cost on top of that.
During my grad school years in India, my advisor had a DEC Alpha desktop. Everything he did was through an Emacs session. God knows how many years old the session was or what was the last boot time.
Memory fails me on whether it was running Linux or another Unix.
Covers a lightweight window manager on Linux, a terminal emulator and editor. I wonder how this person manages modern web browsing on underpowered systems though.
I actually used Firefox at the time of this post but I now use Librewolf. Modern day web browsing actually isn't as demanding as you think it is: I've been able to happily have Firefox open with Discord in it and FreeTube (an electron app for watching YouTube) on a Pentium T4300 with 4GB of RAM.
It was slow but it worked perfectly fine, you just have to have patience to use older hardware. Hope this clears that up :)
(As an aside, my main PC now uses KDE instead of i3wm!)
I have a machine with a N4500, and it's actually fine for web browsing in regular Firefox.
The main problem I experience with it are: 1) Go compile times on some projects, and 2) JS frontend builds.
The Go compiler is fairly fast, but there are some patterns that can make the compiler much slower, and the difference can be pretty dramatic.
I don't do that much frontend stuff and many projects are fine, but some projects are just a horse to build. At my last job it took at least ~5G of RAM and ~3 minutes on my i5-8350U (never tried on the N4500). This is a main reason I bought a new machine; otherwise I'd still be using the i5 (a second-hand x280 I got for ~€200 because the screen on the N4500 broke, although that has magically fixed itself in the meanwhile and now I have 3 laptops).
I tried to use an ancient Asus Chromebox as my main desktop for a while, maybe three years ago. Old dual-core celeron processor, I wanna say 8GB of memory but it might have been 4.
The only usable browsers were very-light WebKit ones, and even then, more than three tabs was no good, and heavier “webapps” weren’t an option, unusably slow. Firefox and Chrome were unusable, period, and “lightweight” options based on their engines are not very lightweight at all. It had to be WebKit.
Wild that with the early ‘00s Web I could browse far more capably on machines 1/10 that powerful.
[edit] I mean, it was a chromebox by brand but I was running Void Linux on it.
I upgraded from an outdated system (Pentium+HDD) only when web browsers started giving me grief. Now I'm on a relatively modern AMD system and it does anything I can throw at it. Debian Stable XFCE4 works very well. XFCE4-Terminal is one of the best terminals out there but doesn't get much recognition.
XFCE4-Terminal, Emacs and Firefox are my Big 3. I use Thunar occasionally.
I use XFWM, it can act as a pseudo tiling WM with wmctrl / xdotool shortcuts.
Many years ago I gave up on X11, etc. to remain in the console and virtual terminals 100% of the time, unless I need to view graphics. I use VGA text mode on NetBSD and something like kmscon on Linux. I use tmux instead of a window manager. Before I ditched X11 I used evilwm.
If you were ok with such a basic editor like nano you'd be just fine using it in those server cases, it still wouldn't justify the need to use a worse option universally, but also gui text editors have been light enough to work on even less powerful hardware of decades ago, so the one doesn't justify it either
I like this philosophy. At home, my dev machine is a Raspberry Pi with Raspberry Pi OS Lite installed to keep things minimal and clean. I added OpenBox, Helix, and Konsole, then I'm pretty much sorted (besides tooling for OCaml & Lua). It's a refreshing change to my work laptop.
This has more-or-less been my setup for over twenty-five years. I've used gentoo and vim that entire time, but have changed desktops a few times (i3 currently, but always something along those lines). All development -- and all writing -- is in terminals.
The difference is that I tend to to work on pretty high-powered machines (not for graphics or gaming, but for audio).
But the main reason I have this set up is that I find the minimalism . . . calming? It's not entirely distraction free, but I just find it easier to work in a kind of low-stimulation environment. I do occasionally work on way less powerful rigs (and way more powerful servers), and it's nice that the basic tools don't change. But ultimately, I think my fondness for this way of working might be aesthetic.
The main reason for me is that terminal programs are just less crappy, because people who develop them try much harder. The terminal itself strikes me as a terrible platform - no text sizes, no fonts, no graphics... People dismiss it as unnecessary bells and whistles but then every other TUI program jumps through ridiculous hoops to reinvent crappy versions of these.
If only the same people developed their programs with the same philosophy (minimal, simple, clean UI and keyboard driven) but in a normal GUI, so that you don't have to abuse Unicode to draw UI and just draw it.
This has been my take on things forever. Power user tools tend to be made as a TUI, which is great in that it lets you work from the framebuffer and over SSH, but it really makes you wonder why we can't have the same conveniences with proper graphics.
I'm in the same boat. I want my computing tools to feel like a musical instrument: stable and predictable, very capable but requires skill and learning to use well, and serves me instead of drawing attention to itself. Let me get into a flow state and focus on the task at hand. Working in a terminal is that.
If UIs are constantly shifting or if there are popups telling you about a "cool" new feature, then that software feels less interested in serving the user and more serving its developers. I don't want the manic Silicon Valley hype-of-the-month when I have other more important things to do than fight with technology that's supposed to be helping me (and me exclusively).
A craftsman becomes a master largely by mastering his tools.
When your tools change every damn week because some faceless soulless middle manager wants a promotion, you can't master the damn tools.
I don't know how anyone is supposed to become a master at programming when the industry standard tooling requires waiting around for tooltips to show up because meaningless icons are "clean"
Not only that, but a master craftsman modifies their tools and builds their own.
But it's not even that tools change every week. When you look at things like VSCode it's hard to make your own. Is hard to shape into an environment for you and instead you should shape to it. I see this in a lot of tools and it's destructive. Everyone is different and there's nothing that can be made for everyone. So a good tool needs to be modifiable, so that people can turn it into the thing that works for them.
It rings true, but on the other end of the fence is management class, who wants and prefers that coders are not craftsmen with custom tooling, but interchangeable gears that can swapped at moments notice. In a sense, they want the same modularity, but at the organization level.
You get what you pay for. Unfortunately it appears many are happy with shit and those that are unhappy are unwilling to pay for more. I'll admit, it can be quite difficult to differentiate shit and quality these days prior to purchase. But at a certain point I think you have to stand up to the management class and take pride in your work. It's their job to manage you but it is also your job to make the best product you can. It's becoming pretty clear a lot of tech has been filled with "yes men" and we're seeing the consequences of this. The bigger problem is that I think a lot of people don't even know they are yes men. Probably doesn't help that we build things that are so technical that the public isn't accurately able to distinguish quality from shit until they are able to feel the two side my side.
I hear ya. In fact, I will go as far as to say that it is only more recent that I call out my direct manager, when what he says something that does not quite make sense ( and it does not help that he keeps changing his mind ) for one reason or another. I think it takes not just experience and confidence, but decent degree of political skills ( and I certainly do lack confidence and political talent ). Not to mention, I distinctly remember feeling ( way back when I first questioned stuff and got punished for it ) that it is just 'easier' to be a 'yes man'.
Yeah, I definitely do not think it is easy, but this is a thing that has been part of (at least) American culture for awhile but it seems we've been losing it. I personally think it is a big part of American success as we all know there are just things you can see "on the ground floor" that are hard to see from higher up. Hell, we even used to have the show Undercover Boss[0] haha. Obviously it is TV but I think anyone can reason through the truth of this.
I'm still working on how to do this right. But I think it is important that all parties recognize the pushback isn't about "us" but since we're on a team trying to make the best business possible. Part of why I struggle with this is 1) I just generally don't care about authority (maybe a bit too autistic lol) and 2) we're all wrong, so being wrong shouldn't really be seen as that bad of a thing. We're talking about pretty complex problems and we're only human with two eyes that must be in the same place at the same time, so it is pretty obvious that we're going to miss some stuff. It's about being less wrong, and if someone is giving you new information from a perspective you don't usually have access to, you sure want to check that it fits your current working model. If not, you're more wrong by not updating.
There's an information asymmetry here that makes things difficult, but a good manager will always listen to their employees BECAUSE they want to better the business. A good culture will allow "arguing" as everyone should be on the same team. As long as the "arguments" can end on good enough terms like everyone is willing to have a beer together at the end of the day. We get heated with our best friends and partners, right? Confrontation isn't destructive, it /can/ be very constructive. But the culture has to be right. Both management and employees need to be happy to share credit when success is made. This is definitely something even low level employees can do to help cultivate these good cultures. Management can do it by not just encouraging this but also watching to make sure it happens and do their best to make sure that success is properly allocated. Otherwise there's a natural incentive for "bad actors" to oversell their possible contributions. That's how you get "Loud Laborers." I think people think just because you're "a small cog in a giant machine" that this means you can have no impact. But the truth is that every cog is critical to the machine. It's just that the small cogs need to align and the problem is that a bad cog can upset the balance of everything. Success is unstable equilibrium.
[0] https://www.imdb.com/title/tt1442553/
Totally agree that the constant churn of new tools which come and go makes adapting to them and truly mastering them feel pointless. But there’s also the well established old things which (according to Lindy’s Effect) will be there for a long time still - things like Vim, Emacs, efficiently using shell. Investing time in truly mastering them seems like a good long term bet.
There is definitely value to be had in using systems that force you to write high-performing code. In the web space we all too often we sit down at high powered macs to write code that will be run by low-end Android devices, and fail to appreciate the consequences.
I'm always wondering about thoughts like this. Although there are likely a humongous amounts of low end devices, as a whole, how much potential return would you get from this group? This is a value judgment and I know many have low end devices for reasons other than monetary and just completely ignoring quantity may not be viable for certain investments, its just an interesting thing. It might be similar to the debate about the cost of handling credit cards vs cash. Cash has its own set of costs that are usually neglected. You could easily get more return by adding features than spending any time optimizing.
> how much potential return would you get from this group?
This reads a bit like "these poor sods can't afford to pay for my app, so why bother", at least to me.
However even if a certain device owner subgroup doesn't represent a potential revenue stream, you can as a developer still profit from also (or even primarily) targeting their devices.
Apps that will run on lower-powered devices will almost necessarily be leaner, and as a side benefit will have less complexity, less dependencies, and, ultimately, less technical debt for you as the developer to manage.
> low-end Android devices
Or even just devices in high-latency environments. This gets missed in development so often. My experience is that 75% of apps cannot handle it and fail to work in all kinds of ~~interesting~~ frustrating ways.
> all too often we sit down at high powered macs
I think you mean you. I don't and never have done that, and I suspect millions of windows developers have not either.
I think they mean them, and the obviously-high percentage of developers that use Macs compared to the general population of users. Which, ironically, skews the percentage of Windows users lower than most other demographics.
In fact, how dare you forget the Linux users when writing your comment?!
Faced with the option to pay higher costs for incredibly good hardware, or to run any of the many *nix distros, you chose to have meh hardware, and a restrictive OS that is built as a GUI first, terminal a distant second.
Just… why.
As someone with years of windows and Linux experience, yes the Linux shell is quite good, but mac bsd shell is terrible, even compared to powershell
Bash is bash, zsh is zsh; how are they different? coreutils differs, sure, and I dislike BSD’s implementation of them, but that’s why gnu-coreutils exists.
When talking about Linux workflows on older devices it is always worth it to remind people of the existence of kmandla[0] and their later website Inconsolation[1]
Too bad they don't seem to publish anymore.
[0] https://kmandla.wordpress.com/projects/
[1] https://inconsolation.wordpress.com/
> Terminal text editors are also lighter due to the fact that the terminal is providing all of the windowing fuss for them and that terminals are light applications in and of themselves due to not having to do much that is extremely novel or intensive on a CPU
I think this is a common fallacy. Fundamentally adding an tty layer in the middle does not make lighter solution, so in almost all cases terminal application+terminal emulator is inherently heavier than equivalent application talking directly to display server.
I think the performance in terminal apps could come from the fact that terminals can use pre rendered, pre cached in GPU, text glyphs covering a fixed size small grid (of glyph sized blocks instead of pixels.) At least that’s what I have wondered - because the terminal UI experience has been always a lot more slick compared to heavy GUI based programs. Feel free to correct me if someone has done actual performance analysis.
The terminal has implicit state. The GUI does not. The TTY layer is doing far less per call than your GUI stack is.
How does that implicit state help with anything if you look at the system as whole? Sure, with terminal applications the costs are spread around in more components, but ultimately the total can not really be smaller. You still have the GUI stack in the end, with terminal apps there is just terminal emulator and tty layer in between.
The terminal layer can exist outside of the GUI. That GUI programs provide emulation for this, yea, adds the whole GUI layer back in so systemically you are worse off.
The application doesn't notice any of this though. So they're easier to develop and the program itself runs faster (is lighter). Which is the specific point the article was making.
VGA cards haven't provided actual 80x25 text mode since forever, so you're still converting to pixels at some layer. Which means you might as well take full advantage of having full control over those pixels, rather than constraining yourself to the patterns that happen to be in your font.
With full control over pixels, you can use any combination of "text" and "graphics" that you want. For example, you could make Vim or EDIT.COM but with a normal mouse cursor and a scrollbar with pixel granularity.
> VGA cards haven't provided actual 80x25 text mode since forever,
Are you sure about that? The memory range still exists and still operates the same as it ever has. The _card_ just does the translation for you.
> so you're still converting to pixels at some layer.
This has /never/ not been true.
> With full control over pixels
Yea, again, you are intentionally not understanding the point the article or myself made. The application in text mode does NOT need to do this work. The application IS lighter as a result.
> but with a normal mouse cursor and a scrollbar with pixel granularity.
And how do you receive mouse inputs? With more code. How do you manage pixels? With more code. Are you understanding that this is PRECISELY the point here?
Generally you're going to need some sort of layer in order to display something meaningful; even if you count ncurses, the tty stuff is way, way lighter than all the rendering code, componentry, and hierarchical dispatch stuff that goes into a typical GUI toolkit. And it can appear on more devices.
> even if you count ncurses, the tty stuff is way, way lighter than all the rendering code, componentry, and hierarchical dispatch stuff that goes into a typical GUI toolkit
But using tty/ncurses does not avoid the costs of GUI, your terminal emulator will still need to have that. So using terminal can only add additional cost, not reduce it.
The costs of, say, xterm (or even konsole) + tty layer are still far less than the costs of the UI layer for a halfway decent IDE. It's a bit penny-wise and pound-foolish to worry about the added cost of the tty layer when the "talking directly to the display server" approach incurs so much more cost, unless you were willing to accept an unusably minimal user interface (worse than any terminal program would be).
Remember, Unix systems implemented tty support in perhaps tens of kilobytes of memory, on CPUs running at single-digit megahertz speeds. Graphical IDEs these days are often frickin' Electron apps.
> when the "talking directly to the display server" approach incurs so much more cost, unless you were willing to accept an unusably minimal user interface (worse than any terminal program would be).
Talking directly to display server simply can not incur more cost than having terminal application and then terminal emulator talking to display server; the talking to display server is something you need anyways, and anything else (like having a tty layer) is just additional cost on top of that.
During my grad school years in India, my advisor had a DEC Alpha desktop. Everything he did was through an Emacs session. God knows how many years old the session was or what was the last boot time.
Memory fails me on whether it was running Linux or another Unix.
I enjoyed this as my Linux GUI for a while:
https://github.com/emacs-exwm/exwm
Covers a lightweight window manager on Linux, a terminal emulator and editor. I wonder how this person manages modern web browsing on underpowered systems though.
Hi, I'm the author of that blog post!
I actually used Firefox at the time of this post but I now use Librewolf. Modern day web browsing actually isn't as demanding as you think it is: I've been able to happily have Firefox open with Discord in it and FreeTube (an electron app for watching YouTube) on a Pentium T4300 with 4GB of RAM.
It was slow but it worked perfectly fine, you just have to have patience to use older hardware. Hope this clears that up :)
(As an aside, my main PC now uses KDE instead of i3wm!)
Thanks for replying!
An ad blocker helps a lot and is essential for doing web browsing on older or underpowered hardware.
What is modern web browsing good for besides engagement and advertising?
Where do you find and read technical documentation?
Generally such websites work fine in older browsers and with JS disabled.
Complaining about things where the engagement failed.
That's the same thing as engagement.
It’s not really. Because engagement stops when you complain. Which means by exclusion it’s not engagement :)
Bad publicity is still publicity. They got you if you complain.
The only winning move is not to play.
I have a machine with a N4500, and it's actually fine for web browsing in regular Firefox.
The main problem I experience with it are: 1) Go compile times on some projects, and 2) JS frontend builds.
The Go compiler is fairly fast, but there are some patterns that can make the compiler much slower, and the difference can be pretty dramatic.
I don't do that much frontend stuff and many projects are fine, but some projects are just a horse to build. At my last job it took at least ~5G of RAM and ~3 minutes on my i5-8350U (never tried on the N4500). This is a main reason I bought a new machine; otherwise I'd still be using the i5 (a second-hand x280 I got for ~€200 because the screen on the N4500 broke, although that has magically fixed itself in the meanwhile and now I have 3 laptops).
I tried to use an ancient Asus Chromebox as my main desktop for a while, maybe three years ago. Old dual-core celeron processor, I wanna say 8GB of memory but it might have been 4.
The only usable browsers were very-light WebKit ones, and even then, more than three tabs was no good, and heavier “webapps” weren’t an option, unusably slow. Firefox and Chrome were unusable, period, and “lightweight” options based on their engines are not very lightweight at all. It had to be WebKit.
Wild that with the early ‘00s Web I could browse far more capably on machines 1/10 that powerful.
[edit] I mean, it was a chromebox by brand but I was running Void Linux on it.
I recently had the pleasure of using an old low-end laptop running Windows Vista from around 2005 which had a lower-end CPU and like 1 or 2 GB of RAM.
It was surprisingly snappy and usable.
I upgraded from an outdated system (Pentium+HDD) only when web browsers started giving me grief. Now I'm on a relatively modern AMD system and it does anything I can throw at it. Debian Stable XFCE4 works very well. XFCE4-Terminal is one of the best terminals out there but doesn't get much recognition. XFCE4-Terminal, Emacs and Firefox are my Big 3. I use Thunar occasionally. I use XFWM, it can act as a pseudo tiling WM with wmctrl / xdotool shortcuts.
I use i3 with XFCE, and I love it. I'm so grateful for XFCE: Boring, stable, and functional.
+1 for XFCE4-Terminal
Many years ago I gave up on X11, etc. to remain in the console and virtual terminals 100% of the time, unless I need to view graphics. I use VGA text mode on NetBSD and something like kmscon on Linux. I use tmux instead of a window manager. Before I ditched X11 I used evilwm.
If you were ok with such a basic editor like nano you'd be just fine using it in those server cases, it still wouldn't justify the need to use a worse option universally, but also gui text editors have been light enough to work on even less powerful hardware of decades ago, so the one doesn't justify it either
I like this philosophy. At home, my dev machine is a Raspberry Pi with Raspberry Pi OS Lite installed to keep things minimal and clean. I added OpenBox, Helix, and Konsole, then I'm pretty much sorted (besides tooling for OCaml & Lua). It's a refreshing change to my work laptop.
Nice! I used an RPi4 for three years as my dev machine and daily driver. Even light video editing was possible, although slowly.
This is close to what I do, but my Window managers of choice is fvwm and cwm depending on screen size.
I dread the day we are forced to move to wayland, in that environment one is forced to use a Desktop Environment or a Tiling WM.
Luckily, the site works well in lynx. The colors under Firefox was atrocious for me.
Ha! Love fvwm. It's been ages since I heard it mentioned in any forum