All these Xorg/X11 problems people complain about... I honestly don't see them.
I've been using Xorg in one form or another since 2005-2006 and frankly since we all got automatic configuration and said godbye to Xorg.conf it's been a very very pleasant experience.
I've been using both nVidia and intel cards, 1/2/3 monitors (in various arrangement) and network stuff (ssh -X and similar), and a videogame from time to time.
Even xterm, with the right fonts, it's a very nice setup. I almost can't see the difference between a gtk emacs window and an emacs session running in xterm-unicode with proper fonts and antialiasing.
Xorg might not be "optimal", but it works very well for me and I won't be switching to anything else until a wayland or whatever reach feature parity (including but not limited to network transparency).
> All these Xorg/X11 problems people complain about... I honestly don't see them.
That's because DonHopkins is shitposting quotes from the Unix Haters Handbook, which came out in 1994 and contains gripes about Unix dating back to the 80s.
The Unix ecosystem, including X11, evolved a teensy tiny bit since then.
It's not as much "the command line", but being able to talk to your computer using a human-like language, instead of pointing with your finger like a baby or a monkey.
Do you know any computer/user interface that is based on writing what you want to do? (instead of selecting it from a small list of possibilities) The only one that I know is the "primitive" command line.
Good answer! (but I prefer typing language with a keyboard, instead of saying it out loud, as I'm not a native English speaker and it feels very unnatural to me).
Yet, is it possible to use siri or alexa for all your computing needs? Can you copy files around, convert a few images from tiff to jpg, download, compile and set up a nginx web server, hack a bit the code of the server and recompile, etc.? Because I can do all of that from the comfort of my "obsolete" command line.
Human-Computer Interfaces have different needs from Human-Human interaction, in particular they need to be unambiguous (which the natural language isn't), very precise and concise.
For these reasons Siri and Alexa would be terrible to perform tasks which would be very quick in a shell. Also Siri and Alexa are not local and not privacy respecting.
This is a great example, but is still horribly limited in functionality. I use my Google home constantly, but I've built a mental model of its limitations and am still frustrated by the "latency" involved when my model assumes it can do something it can't.
But what is there for power users today? AFAIK Unix is the only viable option from a very pragmatic point of view. So it's not about being aficionados, it's about being pragmatic.
Most of them have no effective way of automating their work.
Every piece of software (Excel? Word? Outlook? Autocad? Photoshop?) has its own system of automation if it has one at all, with many of the skills complicated to learn on one hand, and not transferable on the other. On tablets, automation is essentially nonexistent.
Whereas on Unix, there's a mostly-unified system of automation (shell), with mostly transferable knowledge.
If there is nothing in your work that benefits from automation, you wouldn't care. But you'd also be rather special, IME - most people spend a lot of time on recurring and automatable actions they gain no benefit from repeating manually.
I am not an expert of *NIX OS, but in my two years of learning the philosophy of the OS I noticed that almost every implementation of a GUI concept or idea has it origin from CLI, the GUI is just a manner of automating things in a way that once you know what to write to the computer to do what you want to achieve, that task remains in the form of that button, but again in my opinion a button is just another abstraction of an "alias" in the CLI for a command or just a text file whit a script, it is useful for some cases to have buttons, for example editing a video in CLI is not a optimal choice for that task, I mean you can but probably will take you much more time, specially if you don't know the tool, but in the other hand, almost every video editing GUI app uses "ffmpeg" ( a CLI app and library) as it backed, so probably learning ffmpeg will teach you how to use almost every app of video editing out there. Text editing in my opinion is so slow in a GUI except for some programs like emacs, gvim and others (but whit proper extensions), and with a bit of knowledge you can achieve the same or maybe if you are persistent and develop the love for the CLI a more powerful "button" for your development environment that fits exactly your needs, and it immediately gives you more freedom, you never will to wait until the next version of your spyder or what ever IDE out there to make something you want to do, and if it fails you know how to fix it because you wrote it, that said, REPL came from "SLIME" that means "Superior Lisp Interaction Mode for Emacs", ergo, emacs users have been using REPL long time ago before, even before spyder or any "modern" IDE we actually have, that said, there is a plugin for vim too called vim-slime inspired by SLIME, where you can send words, lines, block or whole text files from your editor to other app, lets say tmux, your browser or any others, so vim, vim-slime plugin, tmux and a script to send text from your editor to shell executing python or ipython3 console or python-qtconsole gives you the REPL feature that is so acclaimed these days, and I want to say that since I implemented it for python development until now, it never crashed, so really I do not miss nothing from any IDE out there jeje, I hope some one who read this out there, expanded his main a bit and break some limitations with these little tip!. I'm currently changing mi mind for a better life in the shell, so any useful resource you want share with me or correction to me, will be received gracefully.
Those are useful and beautiful, but they are particular cases of "command lines", aren't they? A bit limited, in that they are only useful for developing on that IDE, and not as a general interface for your computer, but useful command lines nonetheless. I thought you were opposed to command lines.
Back in the 90's, some machines shipped with X authentication disabled, open to the world (SGI IRIX 5.x was one of these.) Back then, few people used firewalls. X11 keyboard sniffing was very common in some circles.
Yes, and Wayland is a pile of shit, so what's your point? Xorg has this one problem, Wayland has countless problems.
Xorg is stable and proven for decades; Wayland has been incomplete and buggy for decades.
I don't run Wayland, PulseAudio, DBUS, or SystemDumpsterFire on my system, and don't miss any of them.
I don't run strange binary code on my system either, so keyloggers aren't really a concern.
I find it ironic that people who routinely shovel foreign binary code onto their system (even automatically downloading and installing it, no less) from untrusted and untrustworthy third parties, are so all-fired concerned about these trifling imagined Xorg security problems.
Please don't do this. We ban accounts that post like this, and have had to ask you not to before.
I'm not going to ban you because you've mostly been posting good comments lately, which is cool. But comments like this do more damage than good comments add value, so please don't do that anymore.
! Convert Meta-x into "ESC x", not "ø"
XTerm.VT100.metaSendsEscape: true
! Allow HT (TAB) in paste; i.e. do not convert to space character
XTerm*VT100.DisallowedPasteControls: BS,DEL,ESC
! Assume window titles are UTF-8 encoded
XTerm.VT100.utf8Title: true
(Add to your ~/.Xresources and/or ~/.Xdefaults file.)
I use xterm because I'm too lazy to switch, I guess. It was never bad enough for me to switch and it's present virtually everywhere, so I don't need to bother installing my favorite niche term (kind of like sticking with bash when zsh was indisputably more awesome).
To the best of my knowledge, one downside is the text rendering is synchronous. Read a character off the tty, try to display it on the screen. It's fine until you go and cat /dev/mem or something like that. Many GNOME-ish terminals use vte which drops frames if it can't keep up rendering.
I also run into problems with bad display managers or DEs that don't load ~/.Xresources or ~/.Xdefaults (looking at you Debian gdm).
I use xterm because it's one of the only terminal emulators that allows me to disable the alt-screen (titeInhibit). Apparently I'm one of the few, but when I vi/view a file and exit, or read a man page and go back to the command line, I still want to be able to reference what I was just looking at.
Indeed, but it's more painful to get these things set across all the systems and accounts I use, even given Ansible. Doable, but titeInhibit is kind of nice. :-)
With Kitty, which I've been playing with and doesn't support titeInhibit, it requires deploying a termcap package everywhere, which is also painful, but I ended up building a version with those escape codes removed, which was kind of a benefit of having to use and deploy a custom termcap.
While Hackernews was busy grooming their Alacritty setup and holding drag races between it, iTerm, and whatever bloated terminal Microsoft came up with to see which could cat a huge file the fastest, I've been just using xterm. xterm -- it's the standard terminal emulator.
xterm:
* actually emulates a terminal and passes a set of compliance tests to determine how VT-compatible a terminal is (other TEs emulate xterm, poorly)
* is still compatible with bitmap fonts
* has a reputation for being slower than other TEs, but that's only because by default it doesn't cheat and commits every screen update. Other TEs, in order to increase their chances of winning the drag race, will skip updates they think you won't see. This can be enabled via a command-line option or X resource in xterm, but makes xterm less compatible.
* comes with every Linux or BSD distro and works fast on nearly any graphics adapter
What is the practical value in better VT compatibility?
I'm not familiar with the history, but I guess this is essentially referring to a standard defined by hardware products from the 1970s? Why is that still relevant?
What i mean is, many other computer standards become obsolete and get replaced. What is so special about this standard from the 1970s that has given it so much staying power?
It is a software standard, influenced by hardware, which has outlasted nearly every other hardware and software standard of its time. Doesn't that strike anyone else as bizarre?
The VT standard is roughly to the application layer what RS232 is to the physical layer: open, easy to implement, and damn near ubiquitous. It makes a nice Schelling point for when you want to throw up a rudimentary UI.
Example: I once worked for a robotics firm that built its own custom batteries. The battery engineers wanted an easy way to monitor battery health and status. So they added code to the firmware to make the tiny microcontroller that monitored and controlled the battery to periodically spit out screenfuls of health information in VT standard. Then, all they had to do was attach a laptop to the battery over serial and start up Windows HyperTerminal, and they had a full (text mode) status display.
This could not be done so easily without a terminal standard that's nearly universally recognized.
That's a really interesting example. I think I'm having a hard time articulating my question, partly because I don't fully understand the entire stack of software and standards underlying a modern terminal app on a desktop. I feel like there is a lot of historical baggage in that stack, but I don't know where exactly, or why. I was using "the VT standard" as a sort of proxy for that historical baggage, but maybe that's not accurate.
I use a mixed environment. My servers are FreeBSD, OpenBSD, and about 5 different linux distros.
I can only get consistent screen output if I use Xterm.
rxvt, Alcrtty (sp?), Konsole, Gnome Terminal and all others that I have tried mungle ncurses, and/or other screen decorations (like using ASCII +------+, or TAB/Space, "decorations").
Even if I do get rxvt dialed in from one client, if I connect from a different workstation with a different client it's all a mess again.
I know xterm is the slowest of the bunch, but it always works with minimal putzing.
Most "modern" terminals are surprisingly buggy (for lack of a better word), that is, they do not conform to the VT100-series specs (and less documented, but well known quirks). Here's a look at some of them: https://tomscii.sig7.se/2020/12/A-totally-biased-comparison-...
> ...it turns out xterm has incredibly low input latency compared to modern terminals.
This boggles my mind. What on earth does a windowed terminal need to do that should result in any latency on a modern machine?
We had full ANSI-addressible displays that ran faster than the eye could read over serial lines in the 1980s. What on earth additional does a terminal program do and why would I want that?
Well, it first needs to take the your input and pass it through the HID subsystem into userspace to the appliction, which then responds to it and sends it to the terminal, wjocj collects the output and then emulates whatever control codes there are, then updates its internal model of whatever PTY thing it is emulating, then sends that to the screen and wait for the window server to pick up on those changes and then double buffer it onto the screen…it's complicated, to say the least.
But my point is that an Ann Arbor Ambassador terminal (with logic, not even an 8-bit processor) talking to a VAX 750 (about 1/2 MIPS, also passing data from kernel into user space) was lightning fast.
The internal processor that does nothing but scan my laptop's keyboard to send events to the "computer" is more powerful than the setup we used to have. Yet the entire thing is slower.
My Mac doesn't draw any faster than the Alto I used in the 70s.
> My Mac doesn't draw any faster than the Alto I used in the 70s.
Yes it absolutely does, you just don't notice because of the increase in fidelity. What was then 640x480 pixels is now a 4K display. The total number of pixels is several orders of magnitude more, the number of colors is now 16.7 million rather than 256, and the complexity of the scene has increased where we now have anti-aliased text and alpha blending.
Also, in the 70s, you have a bitmap font of max 256 characters of equal size. Nowadays displaying text requires font selection, text shaping (incl. kerning), glyph selection, text layouting (incl. line wrapping), glyph pre-rendering, and a final assembly step to get the composite image of all glyphs.
Want to skip font selection? No emojis for you.
Want to skip glyph selection? No ligatures or Arabic or Devanagari text for you.
Want to skip text layouting? No Right-to-Left support for you.
There is a whole crapton of legitimate complexity in the font rendering stack because we don't want to have the constraints of the 70s anymore (only 256 glyphs, fixed font size, monospace font only).
(Sidenote: For those of you who think "I'm fine with monospace fonts in my terminal", I am using a monospace font as well. But "monospace font" only means that all ASCII glyphs are equal-sized, which is a tiny minority of all glyphs a Unicode font supports. I have grown a very strong opinion regarding this topic since I started to learn Japanese and hence want to be able to deal with CJK characters.)
Most terminal usage will be restricted to the English-language software and source code, for expediency reasons or because English is the lingua franca of tech. You can usually get away without RtL and ligature/wide glyph support.
What I would like to see is a terminal that has a default high-performance monospace-only rendering engine, but gracefully and dynamically switches to a different rendering engine that supports the full-blown text layout capability once the terminal detects some input that makes use of these features.
You might be surprised how often you trigger that second code path. For just one example, an increasing number of CLI programs use emoji in their output, whether you like it or not.
I'm actually a great fan of using emoji to spice up terminal output. Most of these would be fixed width too, isn't it? I know there are wide emoji, but most times I see them around one char wide.
X was designed to run three programs: xterm, xload, and xclock. (The idea of a window manager was added as an afterthought, and it shows.) For the first few years of its development at MIT, these were, in fact, the only programs that ran under the window system. Notice that none of these program have any semblance of a graphical user interface (except xclock), only one of these programs implements anything in the way of cut-and-paste (and then, only a single data type is supported), and none of them requires a particularly sophisticated approach to color management. Is it any wonder, then, that these are all areas in which modern X falls down?
Ten years later, most computers running X run just four programs: xterm, xload, xclock, and a window manager. And most xterm windows run Emacs! X has to be the most expensive way ever of popping up an Emacs window. It sure would have been much cheaper and easier to put terminal handling in the kernel where it belongs, rather than forcing people to purchase expensive bitmapped terminals to run character-based applications. On the other hand, then users wouldn’t get all of those ugly fonts. It’s a trade-off.
I mean clearly the blink tag had to go. It was annoying, unsafe, a blight on the web; not at all like CSS3, JavaScript, WebAssembly and whatever that DRM thing was called, encrypted media extensions, was it? Priorities, man!
Thanks for coming out, the X Windows Chapter was my favorite in the book. :)
Xterm has popup menus, though I don't know when they were added. I've blown people's minds when they saw them. There's also the Tektronix vector terminal emulation in a separate window. It's also trivial to modernize it with features like scroll wheel support because of the flexibility of X resources.
Sure: xterm a client of your display and keyboard and mouse, remote input and output services that the X11 server provides over the network.
And at the same time, a web browser is the client of computing and data servers in the cloud, provided over the network.
In reality, there can be many different client/server relationships existing in different directions over the same full duplex network connection. It's really a bi-directional multiplexed messaging channel, not a pure strict hierarchical relationship, and many client/server dependencies can go both ways over the same connection, at the same time. You can even run an ssh that opens tunnels in both directions, then tunnel X and http connections over that.
Once a connection is established, it really don't matter which end initiated the connection (or how many links and proxies and tunnels there are along the way) -- you're just sending messages both ways.
"Client/Server" is an over-simplified way of describing what's possible.
> Only the server, actually serves the graphics to the user.
The server actually serves the user to the remote client.
It's like "you are not the customer, you are the product". The remote program needs to communicate graphically with you, and connects to the X server to do this; therefore, you are not the requester of a resource, you are the resource being served. :)
Think of it in terms of a print server. It's a long-running process that other processes connect to, in order to request a service. It handles the "impedance mismatch" between the clients and the hardware it controls---in the case of a print server, it demultiplexes requests and translates them into something the printer can deal with; in the case of X, it displays the information as requested by the client and provides notifications of events as requested by the client.
I've found the latency of Konsole to be phenomenally low. I can definitely tell the difference between Konsole and GTK-based terminals, but I can't really tell the difference between the latency of Konsole and XTerm.
I use window separation and profiles in Konsole every single day and alarms are handy when needed.
I have a 4K display and terminal has it's own virtual desktop, separating a Konsole window into nested tabs is a must to simplify the navigation between tabs since you can switch to other groups by a single hotkey.
I use profiles to visually differentiate tabs for different purposes (e.g. ssh to hosts with master and replicas of DBMS, which I did years prior to [0] happened), some made for fixing production hosts so they have an infinite logging enabled, and one can alter hotkey schemes with those.
Alarms are just an easy way of triggering a notification when a task is done or failed, saves time and brain resources.
You can get a fair bit of that with terminal multiplexers like tmux. It does not have the ability to style different tabs. But it has advantages too. For example, you can have multiple terms connected to a single tmux session, you can run tmux when ssh’d to a remote server, the tool is not tied to a particular vt.
Not to say your setup is deficient, but I think I understand where the parent is coming from.
For people interested in playing around with different terminal emulators, you’d do yourself a service trying kitty [https://github.com/kovidgoyal/kitty].
It made my experience on high DPI screens far better. You can find it packaged up in the usual places (e.g. Debian).
I believe the software has to take advantage of the GPU. The `foot` terminal renders on the CPU instead of the GPU, but beats GPU-accelerated `alacritty` anyway due to other effiency hacks described on their Performance page:
There are various ways to take advantage of the GPU -- the so-called GPU-accelerated terminals contain bespoke OpenGL programs ("shaders") to do rendering on the GPU. Here's an interesting way of doing it: https://tomscii.sig7.se/2020/11/How-Zutty-works
Hmm I think it's more the case that an application has to go out of its way to not render on the GPU. High level frameworks' basic rendering operations are, of course, always GPU accelerated. They'd be crazy not to be! It looks like Foot is rendering using CPU by talking directly to the compositor.
Right... but doesn't every serious desktop GUI framework already do that? They aren't drawing every glyph every time from the original curves, and where else would they store video data than... the video RAM.
I've recently taken up alacritty (+ tmux), which is fast; nice, and scales on displays sensibly.
I'd been using urxvt w/ a plugin for tabs for eons previously. I'be been mutating my tmux config to match the urxvt + screen binding I've been used to.
I switched to kitty because it supports a killer feature I became accustomed to in iTerm- a keybind for "Open a new terminal in the same directory as the current terminal."
That opens the new terminal in the home directory, right? My keybind opens it in whatever directory I’m already in which I find handy in deeply nested projects.
OMG UTF8! Next I suppose someone will show me how to disable those !@#%ing colour control codes that always make my text blink? I don't want colour. I don't want syntax highlighting. I just want my old-school terminal. Mind you I'll probably have to sacrifice my cherished 8x15bold font (still installable after all these years) if I really want to go UTF8.
Most terminal emulators won't support the -S option. That is needed so that another program can feed data into an xterm that has been created as a child process.
I've seen it used for a modem dial-up program and I've seen it used for the emulation of old computers with serial consoles. It would probably find use with debuggers. Sometimes you just want to pop open a new window, and xterm is the only terminal emulator that will cooperate.
The option parsing is buggy. Only file descriptor 0 works, but that is good enough because of the dup2 system call. Fork, set up the file descriptors, and then exec an xterm like so: xterm -S/0 -T foo -n foo -name foo
I'd love to get the feature, with the exact same syntax, into all the terminal emulators. That would mean that x-terminal-emulator, which is a link to whatever the user installed, would always have the feature.
It's decent and supports direct-color and all the obscure features of xterm of course, that others don't like querying and setting the color palette.
It doesn't support most(any?) of the bleeding-edge sequences for hyperlinks and underline styling.
It may have better input latency than xfce, but what are you running it on, a 486? Maybe for RPi, but—it has poor paint performance as well. It will flash if you try to do animation or scroll a complex screen. Bit of a toss up on the that front.
Anyway I find it useful for testing terminal sequences, but it's a tough sell as a daily driver. Things like tabs and a proper scrollbar are a minimum for me.
For some of us, we just want the fastest terminal out there (in latency and startup), because everything else will be taken care by the window manager or Tmux.
I like composability, to stack software together, like chaining coreutils in bash. Vim inside of Tmux inside of Xterm inside of Xorg on Linux. Every software adds its functionality to the stack, but no more.
I started using st from suckless and realized that met most of my needs, especially when I learned to use tmux properly. In some ways XTerm is the luxury version compared to st. I don't necessarily recommend st, but it is always interesting to learn that you can get by with a lot less than you thought you could. And it helps you learn some tricks you might not otherwise think you needed.
I use st as well. Honestly, the main reason is that I can configure it to use ligatures, whereas the few that offer ligature support aren't terminals that I prefer, and the terminals I like better don't offer ligature support. So, st it is. Otherwise, it's not the best with regard to overall capabilities (though that is because of my limited ability to write my own original patches for it, I suppose), but it's not the worst either.
I don't especially recommend it either, but I like it a lot for my own use. People who don't know how to patch C on Linux are probably not really going to want to use it with the default config.
- xterm just gives up (tried uxterm as well as the .Xresources settings here)
- st prints the arabic backwards (left to right, which I suppose you might prefer if you don't actually plan on reading it), has no colour on the emoji (which again you might prefer!), and completely fails to display the double-composed diacritics (this is a bad one, even if you prefer to KISS)
- I don't know what kitty is doing with the arabic, all I see are some strange rendering artifacts
- sakura (and xfce4-terminal) passes all the tests
Many years ago, I was surprised to find out that XTerm can also emulate a vector-based tektronix terminal.
The only application for it that I found was a previewer for TeX's dvi files that could render on the Tektronix terminal by drawing a lot of tiny horizontal lines.
If you liked the tektronix emulation, also have a look at sixel graphics [1], which also work in an xterm. Helpful if you are logged in via ssh without X forwarding, and need some graphics...
Maybe we have some difference in configuration, but I don't have any perceivable difference between the two - still on urxvt since way back.
Background transparency is the one feature keeping me from considering xterm. I like the URL handling hack in OP, but I'm also a bit married to some urxvt plugins (URL handler, trimming whitespace when copying)
I'll try to take a video of the difference at some point — I use xorg 1.20.8 on macOS 11.1 and it definitely feels noticeable when I type quickly with vsync disabled (through Quartz Debug.app).
> Background transparency is the one feature keeping me from considering xterm.
That's fair. The macOS xorg server has never supported the COMPOSITE extension/xcompmgr/compiz, so transparency/compositing have always been out of the question for me.
> I like the URL handling hack in OP, but I'm also a bit married to some urxvt plugins (URL handler, trimming whitespace when copying)
I sympathize with this — I used urxvt for years and grew to like how it could easily extend itself using perl. Thankfully, I have been able to mirror all of my urxvt functionality in xterm since I switched back. It also helped me simplify my ~/.xresources, which shrank from ~300 lines 10 years ago to 50 (for both my xterm and urxvt configs excluding color definitions, which live in ~/.Xresources.colors).
> but we can hijack it to instead scan the screen for URLs and open the browser
For comparison, rxvt-unicode has perl utils for mouse-less URL selection [1]. Since it's operating within the terminal, scrollback is also available for selection (not just the currently visible screen).
After invoking the selection mode, it's as easy as using j/k to choose the URL and Enter to open or y to yank to clipboard. Installed on Arch with the `urxvt-perls` package.
I have an old laptop that I use to play with Linux and run my home server. It has an not so mainstream ATI integrated GPU and I had a difficult time configuring compton (with i3) to just look good and perform well. With wayland and latest mesa everything just works and is very snappy. It's not perfect though whenever I reboot my machine I have to put my display to sleep first just to make the display work (just shows a blank screen otherwise) but that's a problem with mesa though and nothing to do with wayland.
I have a “window system” on my unix box. You see, in the unix world, “system” means “a bunch of unrelated programs.” But that’s not what I want to talk about here today. I want to talk about overlay planes.
My HP 9000/835 console has two 19" color monitors, and some extremely expensive Turbo SRX graphics hardware to drive them. You’d think that I could simply tell X windows that it has two displays, the left one and the right one, but that would be unthinkably simple. After all, if toys like Macintoshes can do this, unix has to make it much more difficult to prove how advanced it is.
So, what I really have is two display devices, /dev/crt0 and /dev/crt1. No, sorry, I lied about that.
You see, the Turbo SRX display has a graphics plane (with 24 bits per pixel) and an overlay plane (with 4 bits per pixel). The overlay plane is for things like, well, window systems, which need things like cursors, and the graphics plane is to draw 3D graphics. So I really need four devices:
/dev/crt0 — — the graphics plane of the right monitor
/dev/crt1 — — the graphics plane of the left monitor
/dev/ocrt0 — — the overlay plane of the right monitor
/dev/ocrt1 — — the overlay plane of the left monitor
No, sorry, I lied about that.
/dev/ocrt0 only gives you 3 out of the 4 overlay bits. The fourth bit is reserved exclusively for the private use of federal emergency relief teams in case of a national outbreak of Pixel Rot. If you want to live dangerously and under threat of FBI investigation, you can use /dev/o4crt0 and /dev/o4crt1 in order to really draw on the overlay planes. So, all you have to do is tell X windows to use these o4 overlays, and you can draw graphics on the graphics plane.
No, sorry, I lied about that.
X will not run in these 4 bit overlay planes. This is because I’m using Motif, which is so sophisticated it forces you to put a 1" thick border around each window in case your mouse is so worthless you can’t hit anything you aim at, so you need widgets designed from the same style manual as the runway at Moscow International Airport. My program has a browser that actually uses different colors to distinguish different kinds of nodes. Unlike a PC Jr, however, this workstation with $150,000 worth of 28 bits-per-pixel supercharged display hardware cannot display more than 16 colors at a time. If you’re using the Motif self-abuse kit, asking for the 17th color causes your program to crash horribly.
So, thinks I to myself cleverly, I shall run X windows on the graphics plane. This means X will not use the overlay planes, which have special hardware for cursors. This also means I cannot use the super cool 3D graphics hardware either, because in order to draw a cube, I would have to “steal” the frame buffer from X, which is surly and uncooperative about that sort of thing.
What it does give me, however, is a unique pleasure. The overlay plane is used for /dev/console, which means all console messages get printed in 10 Point Troglodyte Bold, superimposed in white over whatever else is on my screen, like for example, a demo that I may be happen to be giving at the time. Every time anyone in the lab prints to the printer attached to my machine, or NFS wets its pants with a timeout, or some file server threatens to go down in only 3 hours for scheduled maintenance, another message goes onto my screen like a court reporter with Turett’s syndrome.
The usual X commands for refreshing the screen are helpless to remove this incontinence, because X has no access to the overlay planes. I had to write a program in C to be invoked from some xterm window that does nothing but wipes up after the mess on the overlay planes.
My super 3D graphics, then, runs only on /dev/crt1, and X windows runs only on /dev/crt0. Of course, this means I cannot move my mouse over to the 3d graphics display, but as the HP technical support person said “Why would you ever need to point to something that you’ve drawn in 3D?”
Of course, HP claims X has a mode which allows you to run X in the overlay planes and “see through” to the graphics planes underneath. But of course, after 3 months of calls to HP technical support, we agreed that that doesn’t actually work with my particular hardware configuration. You see, I have the top-of-the-line Turbo SRX model (not one, but two on a single workstation!), and they’ve only tested it on the simpler, less advanced configurations. When you’ve got a hip, forward-thinking software innovator like Hewlett-Packard, they think running X windows release 2 is pretty advanced.
I stopped using xterm because C-h and C-; bindings doesn't work on Emacs. I'm not sure if there's a way to configure it to make them work but I remember trying to look for such settings and gave up. It's easier to just use urxvt.
xterm is sadly very slow (you see line by line re-draw in midnight commander and things like that) on glamor/GPU accelerated Xorg server on all my ARM devices. I switched to st (https://st.suckless.org/) on my ARM devices, and while it has less features, it doesn't have this performance issue.
I never figured why that is, other than it not being a CPU issue.
I believe it is not buffering draws, although have never checked the source.
Edit: I found this at the arch wiki:
Troubleshooting - Flickering on scroll
Warning: Double buffering may cause non-bitmap fonts to render incorrectly.
Rebuild xterm using ABS and include the --enable-double-buffer flag:
./configure --prefix=/usr \
...
--with-utempter \
--enable-double-buffer
xterm is still the only usable terminal that supports crisp (bitmap) fonts as far as I'm aware. Which is why I'll be using it until we have high DPI screens everywhere. All the other terminals are unbelievable blurry with their antialiased fonts on ~100dpi screens. (Or alternatively, unbelievably ugly, when turning off antialiasing).
I never understood why so few people are bothered. These blurry fonts hurt my eyes.
A tangent but where could I find a good evaluation of Wayland stack (including Weston etc) security? I know the design is often brought up but most vulnerabilities are implementation errors and bugs, and there doesn't seem to be any mention of security (advisories, etc) on the Wayland web site nor does a web search bring up anything that woudl indicate there's any active security focus.
What I'd expect to find is some description of the security guarantees they provide, and some active work (such as fuzzing with hostile clients), and tracking of found & fixed vulnerabilities.
X has had its share of $5,000 toilet seats — like Sun’s Open Look clock tool, which gobbles up 1.4 megabytes of real memory! If you sacrificed all the RAM from 22 Commodore 64s to clock tool, it still wouldn’t have enough to tell you the time. Even the vanilla X11R4 “xclock” utility consumed 656K to run. And X’s memory usage is increasing.
Nobody in 2021 is talking about Sun Open Look. And even that, whatever its faults at the time, was probably less resource intensive than what most HN readers would use to build a UI today. Try running electron on an Open Look era machine.
Obviously yes. But depending on your distribution or locale settings you might have to launch the uxterm[1] wrapper instead of xterm if it doesn't work out of the box.
I've been using Xorg in one form or another since 2005-2006 and frankly since we all got automatic configuration and said godbye to Xorg.conf it's been a very very pleasant experience.
I've been using both nVidia and intel cards, 1/2/3 monitors (in various arrangement) and network stuff (ssh -X and similar), and a videogame from time to time.
Even xterm, with the right fonts, it's a very nice setup. I almost can't see the difference between a gtk emacs window and an emacs session running in xterm-unicode with proper fonts and antialiasing.
Xorg might not be "optimal", but it works very well for me and I won't be switching to anything else until a wayland or whatever reach feature parity (including but not limited to network transparency).
Whatever,