I have often executed `pkill -9 tmux` and saved my day. I hope the rust version can help a bit here?
Edit: As pointed out below, I'm stupid, it's stated in the article and I didn't read that part
1. Rewrite in (unsafe) Rust.
2. Update the code over time, moving towards safe Rust.
To a business, time your developers spend learning things (the hard way) is wasted.
To a hobbyist, taking the time to learn things is time well-spent.
The only reason this is at the top of HN is because of where Rust is on the Gartner Hype Cycle right now.
It's neat, but I wouldn't say useful.
https://www.youtube.com/watch?v=rWMQ-g2QDsI
Some of that video is about stuff you have no use for if you're not a Rust developer, but, some of it is things that would be just as useful to anybody who is comfortable with, as it says, a command line interface.
My dotfiles at https://github.com/nickjj/dotfiles have an install script to automatically get everything (including tmux w/ plugins) set up on Debian, Ubuntu, Arch Linux or macOS. This includes native Linux and WSL 2 support.
Looking forward to check out tmux-rs.
I entirely stopped using tmux when I couldn't use iTerm.
Have you checked out the website? This is a c2rust project. The Rust code is full of unsafe code and probably buggier than the C version, and let us not even mention readability and maintainability. Maybe there is a joke somewhere.
> I threw away all of the C2Rust output and decided I would translate all of the files into Rust manually from C.
The talk about starting with it, realizing it was too rough and changed approach. It's unsafe rust now but next goal at end was a safe version.
Have you read the conclusion, BTW?
It seems automatically translating Rust to C is not a very good idea: "I threw away all of the C2Rust output and decided I would translate all of the files into Rust manually from C.". Neither seems doing it manually: "I introduced many bugs while translating the code. I’d like to share the process of discovering and fixing a couple." Or using AI: "That’s because when using cursor to translate the code it would still occasionally insert bugs, just like me. So, I spent as much time reviewing the generated code as it would have taken me to write it myself."
As a hobby project, all power to you. But otherwise, maybe better not rewrite working code....
Except that the eventual result allows for extension and improvements in a memory-safe language.
Another comment in this thread hoped for "a brand new bulletproof tmux-resurrect". The reason there's a desire for such things is closely related to the limitations of non-trivial programs written in C.
They're harder to extend without bugs, harder for new team members to understand, and so on.
The "irrational obsession" has to do with advancing the state of the art beyond a primitive high-level assembler that was developed in the 1970s.
I find Rust fun and easy for writing system-level code, and I have enormous appreciation for the degree of correctness-by-construction that it can provide. Generally, if it builds, it works, as long as you're making proper use of the type system - make illegal states unrepresentable, as the saying goes. That's very difficult to do with C.
Rust isn't perfect. For most things, I'd rather be using Haskell, ML, or something on that level. But it's still on a completely different level from C, and rewriting the software ecosystem in it can only be an improvement.
Embed, designated initialization, and constexpr are really nice adds.
Statistically it is the most fun language there is, based on Stackoverflow. Portability is just a matter of time like with any language.
I maintain cargo-nextest, a widely-used test runner for Rust. It is possible to write nextest's runner loop in C, but it would be extraordinarily difficult — each test's state machine has dozens of states, there are several dynamic event sources as inputs, and the event loop relies heavily on epoll/kqueue/the equivalent Windows thing, as abstracted out by Tokio. So most test runners written in C don't even try to approach the quality, reliability, or portability of nextest.
It is possible to do this in C, because it compiles to machine code in the end. But would be out of reach for all but the most talented of C teams working over many years, and the portability costs would be massive. As a result, I don't know of a test runner that comes anywhere close to the feature set and portability of nextest that's written in C.
> I think you have no idea how big the C ecosystem is.
I'm definitely aware that the C ecosystem is much larger than the Rust ecosystem.
That's because the conditions created by C make solving this problem very hard, not because the problem isn't worth solving.
It is still a hard problem with Rust, requiring heavy use of async state machines to manage a rather extraordinary level of complexity. But at least it is possible for essentially a solo dev like myself to do in a robust, largely bug-free manner.
> I run my tests using "make" which somewhat poor but does the job.
Right, "make" is indeed not quite a high-performance enterprise-grade test runner with parallel test execution, high-quality reporting, signal handling, dynamic status querying, timeouts, retries, flaky test detection, mutual exclusion between tests, a DSL that lets you specify sets of tests, flexible configuration, archiving tests to run on another computer, sharding test runs, JUnit support, wrapper scripts, setup scripts, and several other features. Make doesn't even properly support Windows, which is table stakes for a portable test runner.
You're welcome to peruse the design documents:
https://nexte.st/docs/design/architecture/runner-loop/ (already linked above)
Rust is not portable at all compared with C code.
C definitely has a place, but "Rust is not portable at all compared with C code" is simply not correct. A lot more Rust code works across Windows and Unix than C code does. Rust's portability story is different from C's, much better in many ways but worse in others. In practice I do think Rust ends up being more portable than C in most practical scenarios -- for example, look at how things like `eza` work on Windows, the number one developer platform worldwide.
It was born in the 1970s and was standardized in the 80s and 90s. It continues to develop. Numerous data types have been added, along with unicode and threads. The C23 standard was released last year.
There comes a point at which it becomes necessary to move on.
C's lack of memory safety covers a broad range of concerns, including manual memory management, unrestricted pointers, null pointers (Tony Hoare's "billion dollar mistake"), buffer overflows, use-after-free, integer promotions, and so on.
Its weak type system is another fundamental limitation, closely related to its limited support for abstraction. The weakness of the standard library reflects this. The weak type system means that the static guarantees it provides are minimal. There were excuses for all this in 1975, there aren't any more.
Undefined behavior is more of an issue in C than in most languages. Again, not something you ideally want in a systems language.
Language-level concurrency support is virtually nonexistent.
Use of textual preprocessing, with limited semantic integration, as a language feature. Aside from the effects on the meaning of source code, it also makes building C programs more complex.
And again, the reason C23 hasn't addressed any of this significantly is because of fundamental limitations in the nature of the language. You can't "fix" these things without developing a new language.
This is an almost childish claim. If they're so easily avoided, how do you explain the enormously long list of CVEs for C and C++ programs?
> I do not think C++, Zig, or Go have a fundamental advantage.
We agree on that. They objectively do not. They're all an attempt to continue the C legacy. Go specifically is particularly ridiculous, having been designed quite recently by people from the 1970s who steadfastly refused to learn any lessons from the last 50 years of programming language development.
To be clear: I'm from the 1970s as well. I learned FORTRAN in 1977. But unlike the designers of Go, I didn't allow my understanding of programming language design to stagnate in the 1970s. I learned things. I studied things. I discovered things.
Do you believe that C is the ultimate in system programming language design? If you agree that it's not, then what are we arguing about exactly?
It's a different way of thinking about languages than most people usually do, but it's been true for FORTRAN since the 1950s and is true to some extent of every language with multiple implementations today.
All of these languages are Turing complete. So ultimately, if you're happy writing code in some language and don't want to change, that's your choice. But the reason Fortran or C or C++ isn't many people's first choice for new projects are closely related to the reasons I've mentioned. There will always be people who want to stick to what they know, but it's not only science that advances one funeral at a time.
I don't follow; tmux-resurrect isn't written in C and is mostly useful to keep sessions across reboots.
tmux has existed for approaching 18 years, and M. Marriott is still actively improving it as of last week. One can actually look at its record over that time, and, if that record is poor, replace proof by unsupported generalized assertion with proof based upon actual evidence.
* https://cvedetails.com/product/20683/Nicholas-Marriott-Tmux....
That is still quite a good record, but my statement stands. It is supported by decades of my experience working in C-derived languages. You don't have to accept my experience or believe my statement, of course, it's all the same to me.
...and before someone moans that I'm a C-fanboy, I'm really not. I've been writing software exclusively in memory-safe languages for 10+ years now. But I'm also pragmatic about when arguments about a RiR (rewrite-in-rust) are sensible and when they're not. In tmux's specific case, arguing about security misses the point.
Also dev time is massively shorter and the time I gain is spent on adding more features and tests.
Would recommend building low level projects in something like zig, if you care about build time and don’t want to use a dependency for everything.
1. anything running in tmux already has execution rights and typically for the same user as tmux anyway.
2. Anyone who wanted to exploit tmux could just run ‘tmux -C’ and automatically get access to literally every interaction within tmux.
3. The software itself is already damn stable. I've never had it crash.
If you’re worried about someone exploiting your terminal then tmux is a terrible option, irrespective of whether it’s with written in C or Rust. And I say this as someone who absolutely loves tmux and uses it every day.
[edit]
And if you're worried about non-security related bugs affecting UX, then a rewrite in any language, regardless of the language, is a worse solution if your application has already been battle-tested for close to two decades. You're much better off creating something entirely new instead of porting code from one language to another because at least then you have new ideas instead of the same application but with new bugs in different places.
I don't say this because of some bias that Rust fanboys will assume I have. I love memory safe languages and think Rust is a great option for new projects. The point I'm making here is that a rewrite doesn't gain much for tmux SPECIFICALLY because tmux is already extremely stable.
In fact the author of this project has admitted that they've introduced bugs with their rewrite. I know it's a hobby project so I'm not being critical of their work. But if we're only interested in reducing bugs then rewriting an existing project isn't the right way to go. Something like Zellij makes more sense because it's offering something new in addition to being written in Rust.
I honestly don't get this relentless defense of 1970s-style programming. Do you think C is the pinnacle of programming language design? No? Then what's your point, exactly?
Have you actually ever encountered such a bug in tmux though? Because I've been using it for around 15 years and can honestly say I haven't.
Yet this rewrite has introduced bugs. I know it's a hobby project so I'm not being critical. But if you're just trying to reduce bugs then rewriting code battle tested code in another language, regardless of that language, isn't the right way to go.
> I honestly don't get this relentless defense of 1970s-style programming. Do you think C is the pinnacle of programming language design? No? Then what's your point, exactly?
Where was I defending 1970s style programming? I wasn't even defending C. In fact the last project I've worked on based in either C or C++ was 10 years ago. Believe me, I'm a fan of memory safe languages ;)
My point was very clear and very specific to tmux. You're just trying to read between the lines and create a whole new argument where there was none.
https://github.com/dotnet/runtime/pull/115762
https://github.com/dotnet/runtime/pull/115743
Or was that comment just a cop-out because Copilot’s results were complete nonsense?
Sorry I know this is not the place to complain, but it would be so nice!
bind-key -n C-Space select-pane -t +1
Ctrl-Tab probably won't work because terminals tend not to recognize it as different from Tab. But you might be able to bind Alt-Tab or some other such combo to cycle through panes in the tmux config. It should just be a one-liner.
I've been working on a Rust-based tmux session manager called rmuxinator (i.e. tmuxinator clone) for a few years now. It (mostly) works and been slow going because ... life but I've recently picked it back up to fix some bugs. One of the last new features I'd added was the ability to use rmuxinator as a library in other Rust programs. I'd like to try forking tmux-rs, adding rmuxinator as a dependency and seeing if it would ... just work as a way to start sessions using per-project config files. I'm definitely not advocating for adding rmuxinator upstream but it would be very nice to have this sort of session templating baked into the "terminal multiplexer" itself.
The other interesting possibility I could foresee is doing things the other way around and having rmuxinator use tmux-rs as a library in order to setup and manage sessions instead of just dumping out shell commands -- which is fraught with edge cases. (Not sure if this is currently possible with tmux-rs, though.)
Once I wrap up the bugfixes I'm currently working on, I may fork this project and give one or both of the above a try.
Regardless, nice work by richardscollin!
Transitioning more software from C to Rust is a great idea.
If you're going to move a project to rust, you'd want to actually make it look like rust. Currently it looks like C written in rust. That doesn't make anyone happy really.
(Obv. not a slight on the maintainer here, it's a personal project with a specific approach)
I wonder, I don't expect.
This would require first for the Rust implementation to grow beyond a POC with code translation. In its current state I doubt it could entice any of the original authors or maintainers. But if it became capable and hardened and picked up velocity, then it would pose some major questions for having two similar pieces of software.
These problems are largely solved now that there's a working transpiler from Rust to C - https://github.com/FractalFir/rustc_codegen_clr
> rustc_codegen_clr is only tested on Linux x86_64, with the CoreCLR runtime (more commonly known as simply the .NET runtime), on .NET 8. It should work on other platforms, but it is not guaranteed.
I guess it could eventually be an option, but today it looks more like a neat tech demo.
0. https://codemod.com/ 1. https://martinfowler.com/articles/codemods-api-refactoring.h...
That’s specific.
I was hoping for the announcement of a brand new bulletproof tmux-resurrect.
But no, it is (just) tmux-(recodedIn)rust.
Now I really wonder how a good model like Sonnet 4 would have performed.
What do you mean by this? I'd assume the process would be very very incremental. One function + accompany tests at a time, verify and continue and keep moving up the tree.
It's an interesting problem because I imagine in the future lots of things will be ported like this.
-edit Good luck reading 100k lines of Claude generated Rust that you know nothing about lol. LLMS are not the tool for this.
> I did start trying out Cursor towards the end of the development process. I ended up stopping using it though because I felt like it didn’t actually increase my speed. It only saved me from finger pain. That’s because when using cursor to translate the code it would still occasionally insert bugs, just like me. So, I spent as much time reviewing the generated code as it would have taken me to write it myself. The only thing it saved was my hands. Doing this large amount of refactoring is really hard on your fingers.
Here I want to call out zellij. Zellij is rust based terminal multiplexer.
I am user not creator. I love everything rust and finding and migrating to rust based solutions where feasible.
In fact, I sometimes port code to another language and back just as a way to do code cleanup (or at least give ideas for things that could be cleaned up)
I wonder why OP didn't start from that as a starting point?
Sounds to me that this was a C -> Rust transpiler. :D
Edit: I was right, they used c2rust.
And then there is "// generated Rust code".
As for the code snippets on https://richardscollin.github.io/tmux-rs/, I can read the C version better than the generated Rust code.
// cmd-kill-session.c
RB_FOREACH(wl, winlinks, &s->windows) {
wl->window->flags &= ~WINDOW_ALERTFLAGS;
wl->flags &= ~WINLINK_ALERTFLAGS;
}
// cmd_kill_session.rs
for wl in rb_foreach(&raw mut (*s).windows).map(NonNull::as_ptr) {
(*(*wl).window).flags &= !WINDOW_ALERTFLAGS;
(*wl).flags &= !WINLINK_ALERTFLAGS;
}
It is auto-generated with the purpose of maintaining the exact same semantics as the C code, with no regard to safety, best practices, etc.—of course it is messier than actual, handwritten Rust.
As c2rust says in its documentation [1], it's meant to be the first step in an otherwise manual and incremental port of a codebase from C to Rust, and the author recognizes this in their closing remarks:
> The next goal is to convert the codebase to safe Rust.
[1] https://github.com/immunant/c2rust/raw/master/docs/c2rust-ov...
Have you read the conclusion, by the way?
It is probably going to end up being vaporware.
Given the traction you got here and the advancements in AI, I'm sure this can become a very attractive hobby project for Rust beginners, there's probably a lot of easy bugs to fix. Fixing bugs, adding new features, and optimizing the code is all you need.
Here's an idea to get the ball rolling: Create a scratch buffer for Gemini CLI (or your favorite LLM) and enable it to interact with the various windows and panes of the tmux session.
Here's my use case, I use synchronized panes to send the commands into multiple servers, but some commands sometimes fail for various reasons. What if I can just ask the AI to send a series of commands and react based on the output and adjust along the way. It's like a dynamically generated custom shell script on the fly.
For example, I'm a daily gvim user. If I were going to do a hobby project text editor, I would emphatically not make a clone of gvim, I'd make a text editor with exactly the features I want that behaves exactly how I want. If you're going to invest that much time in a project, why not do something creative and unique?
120 comments and nobody has mentioned the use-after-free triggered by closing a window. Rust truly is the safest language.
Which makes C2Rust seem pretty useless?
"I’ve recently reached a big milestone: the code base is now 100% (unsafe) Rust. I’d like to share the process of porting the original codebase from ~67,000 lines of C code to ~81,000 lines of Rust (excluding comments and empty lines)."
And yet somehow a hand-ported (and still unsafe) rewrite of a C program in Rust is still almost 20% larger?
If I recall, the Go gc compiler was automatically converted from 80K lines of C to 80K lines of Go. A hand-ported version would have been much smaller.
It does what took him 6 months in seconds. Of course it isn't perfect, failing to keep the name of constants being an obvious flaw. But presumably with a few improvements you could then spend some of that 6 months cleaning up the code and still save time. Sounds like C2Rust is almost there, but not quite yet.
> And yet somehow a hand-ported (and still unsafe) rewrite of a C program in Rust is still almost 20% larger?
Size is not a very useful metric. But the port is still half-done. He has got it working in Rust, so now he is ready to do the "hard" part of the port and actually rewrite the "basically C" code into idiomatic Rust. That is where you expect to get safety improvements and hopefully more readable code.
It generated unusuable garbage code in seconds, which is nothing like what he wrote by hand in six months.
"Size is not a very useful metric."
Size is a very useful metric. Counting tokens is more accurate estimate of "size" but lines of code is a good first approximation.
The entire purpose of high level languages is to make it possible to do more with less code. Size isn't all that matters but it's very important.
Rust code is not only more verbose than C it's also much more irregular and complex. That 20% increase in lines of code is probably more like 50% increase in code complexity, and this is without safety.
Just compare tokens in the post's example:
// cmd-kill-session.c
RB_FOREACH(wl, winlinks, &s->windows) {
wl->window->flags &= ~WINDOW_ALERTFLAGS;
wl->flags &= ~WINLINK_ALERTFLAGS;
}
// cmd_kill_session.rs
for wl in rb_foreach(&raw mut
(*s).windows).map(NonNull::as_ptr) {
(*(*wl).window).flags &= !WINDOW_ALERTFLAGS;
(*wl).flags &= !WINLINK_ALERTFLAGS;
}Love it. You definitively deserve your +350 points!
And as a result, you could be running the greatest / fastest / most feature rich desktop terminal … but if your multiplier doesn’t support something - it hinders your fancy desktop terminal.
Short 3 min video explained by Ghostty creator
you want to re-implement a well known project, fine
call it something else
Like they’ve basically thrown away all the rust patterns and just wrote a c program in rust (eg all the raw pointers)
Works great and it's totally memory safe
What a legend.
The experience with `c2rust` is particularly interesting. It reminds me of a similar shift I saw years ago with automatic code translators between other languages. They're incredible for getting a project off the ground and proving feasibility, just as the author found, but you often end up with code that's completely "un-idiomatic" for the target language. The decision to throw it all away and do a manual port, while surely gut-wrenching, was the right call. You just can't automatically translate the intent of the original C code into safe, idiomatic Rust.
The "Interesting Bugs" section gave me flashbacks. Bug #2, with the mismatched struct layout due to a missing `*`, is a classic FFI (Foreign Function Interface) nightmare. I once spent the better part of a week debugging a similar issue between C++ and C# where a single change in struct packing alignment was silently corrupting data downstream in very subtle ways. It's one of those bugs that makes you question your sanity. Finding that requires some serious debugging grit, so kudos to the author.
This project is a great case study in the real-world challenges of modernizing critical infrastructure code. The author mentions the next big goal is to convert the codebase from `unsafe` to safe Rust. I'm really curious about the strategy for that.
Refactoring away the raw pointers and complex control flow (like the `goto` patterns) into safe, idiomatic Rust without breaking everything seems like it would be even more challenging than the initial port. Will the approach be to introduce lifetimes and the borrow checker module-by-module? And what's the plan for the intrusive data structures? Replacing them with standard library collections like `BTreeMap` is the obvious choice, but I wonder if that will have performance implications that the original intrusive design was meant to avoid.
In any case, amazing work. Thanks for sharing the journey in such detail. I'll be following this project on GitHub for sure.
mbreese•10h ago
I love this attitude. We don’t necessarily need a reason to build new things. Who knows what will come out of a hobby project. Thanks to the author for the great write up!
Also, my gardening is full of segfaults, coding a new project is definitely safer to my yard.
upmind•10h ago
ziml77•8h ago
phkahler•7h ago
nisegami•9h ago
Edit: apparently it did turn out to be a lot of unsafe code
miroljub•9h ago
Every new project is bound to have bugs that need to be ironed out during the time.
Ar-Curunir•9h ago
a_humean•9h ago
nicoburns•6h ago
antonvs•9h ago
You'd have to do a proper rewrite, in which case you could write safe code from the start.
> Every new project is bound to have bugs that need to be ironed out during the time.
Not on the level of the kind of critical security and reliability bugs that unsafe languages foster. That's why CISA and the FBI both strongly recommend memory-safe languages.
QuaternionsBhop•8h ago
nicce•8h ago
Jtsummers•9h ago
ar_lan•7h ago
> the code base is now 100% (unsafe) Rust
I didn't interpret that it's 100% unsafe, but I do expect that to mean there is probably a lot of unsafe blocks used. A good amount of the example code in the post alone is unsafe blocks as well.
cultofmetatron•8h ago
interesting, I'm new to rust. what are you doing that necessitates using unsafe?
tshaddox•8h ago
jeroenhd•8h ago
C pointers can have as many owners as you want, may be subjected to mathematical operations, and can be cast to any type without even an error message. The compiler will just assume you know what you're doing. If you enable enough compiler warnings, it might warn you, but C compilers don't generate a lot of those by default.
Rust will let you only generate one mutable (exclusive) reference at a time. This means straight C to Rust ports simply don't compile.
By switching to pointers, which work pretty much like their C equivalent, you can port the code much easier, but you do of course lose the benefits of Rust's safety mechanisms, because most pointer operations throw away all the safety guarantee that Rust provides.
SoftTalker•7h ago
cuu508•7h ago
petrzjunior•7h ago
kevincox•5h ago
sedatk•2h ago
zozbot234•4h ago
Safe Rust includes many forms of shared mutability, including Cell<> which is perhaps the closest comparison to typical patterns in C code.
krater23•3h ago
anyfoo•2h ago
planet36•8h ago
tombert•8h ago
I recently rewrote `fzf` [1] in Rust. Did I have any particular reason to do so? No, not really, regular `fzf` is fine, but I thought it would be a fun excuse to learn how fuzzy search algorithms work and how to exploit the channels in Rust. It was fun. There's no question that regular fzf is better but that wasn't the point, the point was to play with stuff and learn.
[1] https://github.com/Tombert/rs-fzf-clone
carlmr•5h ago
[1] jhawthorn/fzy: :mag: A simple, fast fuzzy finder for the terminal https://share.google/TBp3pVaFngBTfaFyO
tombert•5h ago
Someone smarter than me who is more familiar with TUI programming could almost certainly augment and improve what I wrote; I worked on it for as long as it was interesting to me. I use it for my home-built program launcher thing Sway, though most people would probably get better results with real fzf.
[1] https://github.com/Tombert/rs-fzf-clone/blob/main/src/helper... [2] https://github.com/Tombert/rs-fzf-clone/blob/main/src/proces...
rauli_•7h ago
dsp_person•6h ago
godelski•6h ago
And frankly, to quote Knuth
This is true for any field, or any project. We're creative creatures. We dream and explore. Major changes almost never come from doing things the way they've always been done. A lot of times "just because" gives you the freedom to try new things and challenge those paradigms. Weirdly, if you always have to justify everything you slow down progress.Arisaka1•5h ago
godelski•4h ago
To me it sounds like you learned a real important lesson one that some people never seem to learn.
I think one of the most beneficial aspects of doing things "just because" is these other skills or information you get along the way. It is very easy to miss all of this progress if you're too focused on the progress of the more tangible things. But that doesn't make any of that not progress. So don't put yourself down for that, because I'm sure you learned a lot. The only reason you can look back and see a better way is because you made that progress and learned those lessons. These are things mentors can usually help you get through faster but not everyone has a mentor nor access to one. But don't undermine your own progress just because you didn't finish projects or because you did things differently than others
ku1ik•4h ago
serial_dev•4h ago
I treat projects differently if they want to launch a product, they want to replace an established open source tool, done for fun for themselves, or if it’s a hobby project.
godelski•1h ago
Follow up questions are totally cool but the context is different, right?
If it isn't acceptable then there's a negative tone and questions are focused on utility and usually them "trying to help you" find utility.
If it is acceptable they ask you about your interests and what you're learning. Sometimes that can turn into utility but that's more natural.
It's a lot about culture to be honest. Some people are just toxic and if things don't make sense in their heads then it doesn't make sense in any head.
charcircuit•3h ago
badgersnake•5h ago
Or copies of old things apparently.
90s_dev•4h ago
1vuio0pswjnm7•3h ago
But tmux isn't new
Is a reason necessarily needed to rewrite software in other languages
fragmede•3h ago
magarnicle•2h ago
usef-•4m ago
The latter reason is why Helix hasn't fully replaced vim, I think, despite being far better designed and friendly defaults.
I've still never switched from screen, personally, though I'm only a light user.
sherburt3•2h ago