I’m really excited to share that Warp is now available on Linux! If you’re interested in trying it out, you can download Warp at https://www.warp.dev/.
We've gotten 2-3 reports of authentication issues like the one the author mentions. We are actively looking into it; we believe its an issue with a library we depend on to open URLs. If anyone is experiencing these issues, please contact us at support@warp.dev so we can better understand the issue and further debug!
Building Warp on Linux was quite an undertaking. Warp uses a custom Rust-based UI framework that we built in house and renders natively on the GPU. To get Warp running on Linux, we built a version of our UI framework that supports winit [1] as a windowing backend. We also built a version of our renderer that uses wgpu [2]. Reducing complexity by using these well-supported, cross platform, frameworks let us bootstrap a version of Linux quicker than expected and should make it easier to build Warp for other platforms (like Windows).
Please let me know what you think! Happy to answer any questions, either about the product or about technical challenges.
I’m really excited to share that Warp is now available on Linux! If you’re interested in trying it out, you can download Warp: https://warp.dev/
Building Warp on Linux was quite an undertaking. Warp uses a custom Rust-based UI framework that we built in house and renders natively on the GPU. To get Warp running on Linux, we built a version of our UI framework that supports winit [1] as a windowing backend. We also built a version of our renderer that uses wgpu [2]. Reducing complexity by using these well-supported, cross platform, frameworks let us bootstrap a version of Linux quicker than expected and should make it easier to build Warp for other platforms (like Windows).
Please let me know what you think! Happy to answer any questions, either about the product or about technical challenges.
I'm trying out Warp for the first time, and an immediate accessibility issue for me is that the text is simply too small to read for a lot of the UI elements (context menu, side bar, tab bar…). The size should be configurable for all of the elements, not just the terminal view. I think I would also be fine with a setting that just scales the whole UI.
Hey there, thanks for feedback. We built our own UI framework in Rust to build Warp, and there were some initial rendering quirks--especially with rendering text on low resolution monitors.
I'd love to hear more about the rendering issues you've faced when using Warp so we can fix them!
Hey there, engineer from Warp here. Warp never collects input or output from the console. There is only high-level tracking for monitoring app crashes and some feature usage data. Our philosophy is total transparency around telemetry. We’ve created a Network Log tool you can use to watch all events in real-time [1] and we have a full list of telemetry events we record in Warp’s docs [2]. You can also opt out of telemetry in Warp’s settings.
Warp requires a login to support its collaboration features (for example sharing commands with a team). Login makes it possible for developers to collaborate securely.
> Warp requires a login to support its collaboration features (for example sharing commands with a team). Login makes it possible for developers to collaborate securely.
So if I don't care about collaborating, can I use it without an account?
> Login makes it possible for developers to collaborate securely.
Is that the only way for developers to collaborate securely? Aren't there other technologies out there can enable secure collaboration without requiring me to sign up for yet another centralized, opaque, data vacuuming operation?
You are never going to get broad adoption if you require someone to sign up to use something locally. Full stop. People who will install any software that comes across Hacker news are going to pause the moment you make them sign up to use a local application.
All of the explanations about how it's not intrusive and only collects X, Y, or Z doesn't matter. There are many apps I use that send crash reporting data, and the only time they do that is when they crash and then they ask me if it's ok. I don't have to sign up to do that.
I'll install and try this as the interactive suggestions look nice (finally, software that can RTFM for me - nice! :) , however, from your description of the purpose of login, couldn't the same effect be gained by locally creating a unique (for warp interaction) ssh key that preserves privacy and yet allows developers to securely communicate by sharing their public keys. A similar process might offer more comfort in deciding to allow the telemetry.
I've been making clear ice at home for a while--it's a great party trick and much easier to do than it seems.
The best part is chiseling ice cubes from a large clear block of ice: use a serrated knife and a hammer and you will end up with perfectly square blocks of ice.
Disclaimer: I work at Warp (warp.dev) and wrote the initial How Warp Works blog post (https://www.warp.dev/blog/how-warp-works) that discusses why we chose to write our own UI framework.
This is a great article! Writing a custom UI framework to render on the GPU is a big cost--but it has been worth it for us. It has let us build a UI-heavy terminal while continuing to match the performance of some of the fastest terminals on the market (such as Alacritty). There is certainly an initial velocity hit for new engineers as they have to learn the semantics of our framework, but overall I wouldn't say it has a big detriment on our velocity as a consumer of the framework.
The callout to a11y is a good one--we have basic a11y support but it is by no means robust. There are additional downsides to building your own GPU-rendered UI framework other than a11y that I want to call out: you have to build most of the interactions with the platform yourself instead of getting it for free when rendering using system APIs.
One example of this is properly supporting i18n. A robust framework should support RTL text, positioning IME / the emoji picker, so forth. While implementing these yourself is doable (we have decent support for IME at Warp, for example) it requires an engineer or two to spend a few weeks to implement.
For Warp, this has definitely been worth it, but it hints that the community needs better cross-platform GPU-rendered UI frameworks so people don't need to consistently build them themselves.
I don't want to brag, but I wrote GLterm (for OSX) in 2002 or so, first ever terminal emulator using OpenGL... It was a shareware tho (it was all the rage back then)...
In fact I probably reported and had ATI and nVidia fix bugs that even made it possible to have pixel aligned textures, partial refreshes of GL surfaces etc. It was all basic stuff, but it was always overlooked because "gaming"...
I find it hilarious that the GL UIs are all trendy now, I've done many of them professionally for the last 20+ years. One of first one was Sibelius v2, a desktop software for writing (engraving) musical scores, I converted the windows GD code to a GL backend all the way back then, rendering in textures etc etc.
Interesting terminal, sadly not yet available for other platforms than Mac.
I went to your GitHub (https://github.com/warpdotdev/Warp) in order to see if I couldn't figure out how to build it for Linux, but seems that's like a "issues" repository and I cannot find the source code anywhere, nor is it linked on the main website (https://warp.dev).
I'm guessing at this point that it's on purpose? The source won't be available and it's only a closed source product?
They've talked about it being on the roadmap for a while, but I'm not aware of any recent advancement in getting it to work cross-platform (much less publishing the source).
Indeed, "at this point" they've demonstrated that cross-platform development is a low priority for them. Even if they do ship a Linux client, I feel like it will be a hard-sell when there are so many other terminals treating Linux like a first-class target.
First off: thanks for sharing! Warp is building some real innovation in a Terminal, and it’s been a blast to follow the project.
It’s interesting that you mention this now - I’ve been a Warp user for a few months but just yesterday started seeking out another option because the UI has been feeling sluggish in Warp.
I installed alacritty and kitty, and they both feel insanely fast, comparatively. iTerm is approximately the same as Warp.
I think the difference is significantly smaller than most people would intentionally target with UI paints. But when I press enter, it feels like warp just has a minuscule delay, where kitty has instantaneous printed the results within the same frame that my finger hit enter.
Do you know if there’s a specific # of ms that Warp is targeting for a UI response from user input? I’m not at all an expert in this domain, but am curious if it’s “all in my head”, or if there really is a difference here. Do you have similar stats for other terminals?
Edit:
Only asking because I know it’s hard to get the right balance between extra feature & speed. The autocomplete & syntax highlighting are really awesome features that I love about Warp, and those likely take many more CPU cycles. Warp is far more powerful than kitty in that way. But how many ms does it cost to have those features?
I know the answer isn’t the same for everyone about what the right trade-offs are between features and speed, and I haven’t made up my mind yet which is more important for me, to be honest. Warp is crazy impressive and has been a step up in functionality. Again, really love the work you’re doing!
Would be great for the rust community and also for warp's rep among developers if y'all opensourced the UI framework. The rust ecosystem just doesn't have a good answer when it comes to choosing a UI lib yet.
I was shocked to find that there wasn’t a fully fleshed out text rendering engine for WebGL.
On the one hand I think you could argue that if you have a lot of text maybe html would suit your needs better. On the other hand a lot of UIs just need some text and it’s so east for it to look like junk.
There's an entire layer of mid-level web APIs missing to better connect WebGL and WebGPU to all the other browser systems (like text and DOM rendering).
Ideally canvas with WebGL and WebGPU would sit at the bottom of the browser API layer cake, the DOM at the top and squeezed inbetween public APIs for text, shape, CSS+HTML rendering. But instead we got this weird canvas thing dangling off as another high-level DOM element.
Totally. It would be /amazing/ if I could leverage the browser's existing (and largely excellent) document and text layout engine from /within/ WebGL. Let me build up my UI as I want, and inject a DOM into that.
We are actively working on making telemetry opt out. We are very sympathetic to concerns about telemetry and data collection and try to be as transparent as possible about what we collect and why. We only collect metadata and never command input or output (you can see the full list of events we track here: https://docs.warp.dev/getting-started/privacy#exhaustive-tel....
We initially required telemetry for all users while in beta so that we could have a better understand of usage patterns and improve the product in its early stages. As we mature, we are able to better extrapolate from a larger sample size without requiring telemetry.
You can launch vim within Warp without any problems, but vi/vim mode for the line editor itself isn't supported in Warp just yet. You're correct that this is because we'd need to implement VI mode ourselves (tracking issue here [1] if you are interested).
This is the tradeoff of building our own editor instead of using the shell's--we can build features that wouldn't be possible in the shell directly but it requires us to build features that already exist in the shell from scratch. So far, this tradeoff has been well-worth it to build what we think is a better experience when using the terminal.
Thanks for the answer! Still curious, how does vim work in Warp? Do you know what process are currently running and then you stop buffering the chars and you pass them directly to the process in foreground? I didn't read the code, but from the article it seemed that you pass the text to the shell only when pressing enter, I think in vi(m) you want to do it the whole time (?). If I want to insert something I just type `isomething to insert<Esc>`. How does this work in Warp? What happens if I put the process in background and then in foreground again?
Thank you for your kind words! We are planning to first open-source our Rust UI framework, and then parts and potentially all of our client. We want to make sure we get this right, both for our users and for Warp.
Our current best-guess on how we'd do this is a more restrictive license that
* allows for verifying security and privacy
* allows individuals to build and tweak Warp
* prevents another company from starting a commercial enterprise off of it
I’m really excited to share that Warp is now available on Linux! If you’re interested in trying it out, you can download Warp at https://www.warp.dev/.
We've gotten 2-3 reports of authentication issues like the one the author mentions. We are actively looking into it; we believe its an issue with a library we depend on to open URLs. If anyone is experiencing these issues, please contact us at support@warp.dev so we can better understand the issue and further debug!
Building Warp on Linux was quite an undertaking. Warp uses a custom Rust-based UI framework that we built in house and renders natively on the GPU. To get Warp running on Linux, we built a version of our UI framework that supports winit [1] as a windowing backend. We also built a version of our renderer that uses wgpu [2]. Reducing complexity by using these well-supported, cross platform, frameworks let us bootstrap a version of Linux quicker than expected and should make it easier to build Warp for other platforms (like Windows).
Please let me know what you think! Happy to answer any questions, either about the product or about technical challenges.
[1] https://github.com/rust-windowing/winit [2] https://github.com/gfx-rs/wgpu