Another option, as indicated above, is tauri, but I personally wouldn't want my terminal to be written in a js/ts framework. There was a terminal app that went with that approach, don't remember the name unfortunately, and it just felt slow, though it was using electron I believe, so mb it wouldn't be as bad with tauri, but can't tell for sure.

Yeah you're probably thinking of Hyper. Seeing as the warp devs are compiling with WASM that should keep things fast. Also Tauri is built with Rust and is more lightweight than Electron so it may turn out to be a good combination. I'm excited to see what they come up with. 👍

Yeah you're probably thinking of Hyper. Seeing as the warp devs are compiling with WASM that should keep things fast. Also Tauri is built with Rust and is more lightweight than Electron so it may turn out to be a good combination. I'm excited to see what they come up with. 👍

Correct, Hyper was it. And ye, that's why I said I can't be completely sure that web frameworks are a bad choice, since tauri is actually good🤣

Maybe I'm missing something, didn't the devs build their own UI framework from the ground up? Is there a reason to believe they wouldn't port it to Linux, rather than use GTK/Qt? Or am I completely misunderstanding how the pieces fit together here?

Tauri is honestly not the best option for linux primarily because (last time I checked), there is no way to explicitly set the backend to be wayland, and it defaults to X whenever the application uses global hotkeys. It even seems to override or ignore the env variable GDK_BACKEND=wayland

Voting for GTK4 with Libadwaita components.

It's pretty easy to use from Rust (It's basically like manipulating DOM elements with vanilla JS) and looks great. I am sure there are frameworks out there to make it easier to work with but it has been fine by itself for me.

Supports Wayland out of the box and Gnome is shipping a Vulkan renderer in the next few months.

I'm assuming mostly low-level graphics work, since they wouldn't have to port it if they were using vulkan/wgpu (mb small tweaks here and there), since it's cross-platform by default. And bc it has been mac-only, I'm assuming they were using metal for graphics, which cannot be used on Linux/Windows

webgpu can target vulkan, metal, and direct3d 12, if they rewrite their graphics in webgpu then it should be write-once-run-everywhere

webgpu can target vulkan, metal, and direct3d 12, if they rewrite their graphics in webgpu then it should be write-once-run-everywhere

Oh true, forgot it can do metal as well

We built a wgpu implementation of our renderer as part of this effort that we intend to use as our backing renderer on Linux, Windows, and the web.

Once we do enough performance testing, we also plan on replacing our Metal renderer with the wgpu renderer so we don't need to maintain two different implementations of our renderer :)

X11 should be really considered deprecated. Wayland support should really be the primary goal and X11 support if there's time, not the other way around. Good to see winit covers both though!

I can't speak for Nvidia GPU owners but I have been using Wayland for the last 2 years on Gnome 4x and haven't had any issues. I would be fine if this were Wayland-only, especially if that means a smoother experience that is easier for the team to maintain.

I can't speak for Nvidia GPU owners but I have been using Wayland for the last 2 years on Gnome 4x and haven't had any issues. I would be fine if this were Wayland-only, especially if that means a smoother experience that is easier for the team to maintain.

I have an Nvidia GPU, and wayland is great; it's X11(or Xwayland) apps that tend to fail spectacularly

X11 is too old , I think

When you take an already fragmented platform that is linux and then divide that in half by what compositor a system is running

Compare that to Windows, though, where the single API (some of the features dating back to DOS) is a nightmare to work with and will never, ever change.

The single API? euh... ok. And never changes ? euh.. anyway, so much ideology, so little knowledge.

Given that Warp developers target WASM (or x86_64-unknown-linux-musl?) on Linux, it would probably be a single executable, hopefully statically linked, so the packaging would be extremely easy: only one file to add, apart from the .desktop and the permissions needed (which for a terminal emulator would be full access to all filesystem, etc).

Ye, that I can't argue with, I'll admit. I guess I was talking just more generally about all kinds of software written in all kinds of languages. Rust applications are definitely the easiest ones to package in my experience (of course there are exceptions but on average I perceive it to be true, but let me know if stats (if there are any) prove otherwise)

To clarify here - use of WASM to make a version of Warp that runs in a web browser is unrelated to the work to port Warp to Linux. Linux releases of Warp will be good old fashioned ELF binaries (with specifics of packaging and distribution still TBD). But yes, Rust's tendency towards statically compiling all dependencies into the binary itself (as opposed to relying on shared dynamic libraries) should make this significantly easier.

Anyone mentioned cargo binstall yet? Completely distro (and platform) independent and does not require compiling from source. The only downside is that it assumes that that the user has rust toolchain installed locally, but i think as one of the options it would be perfect.

I use Fedora so I am happy with whatever works there. I'd honestly be fine with a straight up executable I download from the GitHub releases section and a list of dependencies to install.

curl -L --url .../linux-amd64.tar.gz | tar -xvzf - -C $HOME/.local/warp
sudo dnf install gtk #... maybe not needed?

It'll be largely statically linked so I don't imagine there will be many (if any) dependencies to install.
Maybe open the wiki up to the community to maintain up distro-specific install instructions?

I think it's not really important, but don't use snap, snap is so awful.
If you won't add it into the software sources, I think .tar.gz is the best one.

image

I want to get updates here but not 30 emails about "please flatpak"

Yea well that hornets nest has been stirred. This will only end when someone closes the discussion at this point from my experience with literally every other piece of linux software. lol

Yeah, but we can be better. @Mte90 has specifically said that he wants to stay informed, but that he cannot if he is being spammed. So... let's not spam!

To make this discussion easier for anyone and especially the developers to follow, please don’t start new threads when one already exists for the subject matter. Release and package formats are discussed in this thread.

they wrote on top that they are experimenting and that is not yet available.

2. Does this mean I'll be able to start using Warp on Windows by installing the Linux release on WSL2, or is it not that simple?

Most likely this will not be feasible, but wsl2 supports graphical X11 apps, more or less, so maybe?

I'm not positive if that would be feasible, but we do plan on building Warp for Windows once we've wrapped up building Linux (no concrete timeline just yet).

Windows provides a "PTY"-like interface which makes our lives much easier.

We also intend to build support for Powershell as part of building Warp on Windows.

Please keep in mind when you start working on Windows support that WSL support is a must-have for most people (myself included :D). Fortunately, if you follow the new PTY interface that Microsoft introduced for their Windows Terminal to work, there isn't much additional work to do in order to support WSL.

Absolutely--we also considering supporting WSL a must :) I didn't mention it above because there isn't much additional work for us to support WSL for the exact reasons you mention

X11 is Legacy. WSL2 Supports for Graphical Wayland apps

Already answered here: #3602 (reply in thread)

The Wayland Support is a must-have

Import such functionalities implemented in host languages

with the limitation of being restricted to only what can be implemented in memory*

without native bindings, vanilla WASM (aka, WASM without WASI) can't do any IO. as such, if the host language has a filesystem implementation, it'll be restricted entirely to being in-memory, and without any way of saving the data - so if you exit the program and then reload it (or just start another process of the program), there will be no saved state

since these functionalities are usually provided by the WASM runtime (which is more standardized and atomic)

the existence of WASIX isn't standardized at all :) wasmer got too antsy and released it without working with Bytecode Alliance, which means wasmer isn't wasi. wasi preview 2 coming soon though, and should support what most WASI apps would need

or by ourselves through component model (which, however, is not supported widely in current).

it's not even "officially" released yet! hopefully by EOY. and i doubt wasmer will support it, since they're... doin their own thing

see more: https://bytecodealliance.org/articles/webassembly-the-updated-roadmap-for-developers

To clarify here - use of WASM to make a version of Warp that runs in a web browser is unrelated to the work to port Warp to Linux. Linux releases of Warp will be good old fashioned ELF binaries (with specifics of packaging and distribution still TBD).

wasmer got too antsy and released it without working with Bytecode Alliance, which means wasmer isn't wasi

This is not only technically wrong but is also misleading. WASIX preserves full API compatibility with WASI Preview 1, while WASI Preview 2 is a breaking change from its previous version.

Of course, we (Wasmer) did not agree to make any breaking changes and as such we created a new standard closest to POSIX that built on top of the previous working version... hopefully that will be useful for some. If you think the component model is for you, go all in... of course! But that may not be sufficient for many! (especially if you want to use sockets, threads, forks, signals, or many other features)

I also think Warp would really benefit from Wasm and WASIX. So happy to help in case help is needed!

https://discord.com/invite/warpdotdev

Also, your account needs to get whitelisted for the beta. Otherwise, you can't login.

@noahzweben Attention attention please 🖐🏻🖐🏻 waiting for so long here 😃

Everyone wanting to join the beta need to go here ==> https://discordapp.com/channels/851854972600451112/1184925886487724063

@eosdev-x is there an invitation to join the server? I'm unable to see this channel.

https://discord.com/invite/warpdotdev

any updates, waiting like hell for this Time Warper

Ok 1. Why are you not able to wait? What's the urgent use case that can't be solved by using an alternative solution? The product is simply not ready, and I can't think of any particular feature of Warp that makes it an irreplaceable solution...
2. Spamming the list doesn't do anything. There must be deduplication logic in place. And even if you use different emails, the first one was already the highest priority you can get if the list is on a first come first serve basis.
3. There were early build and instructions previously shared in this topic. I downloaded them and tried bit they didn't work on wsl just yet. There were no credentials required to test. You don't need someone else account.
4. Did you already join the discord server? It's faster to ask for instructions there than nagging here.

i'll answer you step by step:

1. I am waiting since september 2021, since i heard they started Warp on Linux, no urgent use case but its the first time i heard AI enabled terminal, i saw fig.io but they have disabled signups coz they have integrated with AWS.
2. I guess spamming the same email again and again works coz i got an email from Warp that i am allowed access.
3. There's no early build right now, they are in Beta right now and we need a whitelisted account to have access to warp as its a private beta.
4. Yeah i am in the discord server already and i've posted about letting me access a few times in the server

@daUnknownCoder
Maybe you will temporarily be satisfied with such a decision?
ollama
& script to install:
webinstall.dev
Of course, it is local, and if you lack computing power, then it is unacceptable.

Amazing!

How about windows? Could then warp be used on Windows through WSL?

@EliteAMDGamer Yes, it is installed.

I'm also having issues with hidpi and wayland. Using latest hyprland with xdg-desktop-portal-hyprland and xdg-desktop-portal-gtk installed.

Anyone find any flags or env vars yet?

Not yet, but I'm sure as heck lookin'.

I've found a workaround using a shell script to be able to pass commands to warp-terminal usage is just call the script with the command as the first argument (in quotes if there's spaces):

#!/bin/bash
# Check if warp-terminal is installed
if ! command -v warp-terminal &> /dev/null; then
 echo "Error: warp-terminal is not installed or not in PATH"
 exit 1
fi
# Check if xdotool is installed
if ! command -v xdotool &> /dev/null; then
 echo "Error: xdotool is not installed or not in PATH"
 exit 1
fi
# Check if an argument is provided
if [ $# -eq 0 ]; then
 echo "Usage: 0ドル <command>"
 exit 1
fi
# Launch warp-terminal in a new tab
warp-terminal &
# Wait for the terminal window to appear
sleep 1
# Send commands to the terminal
xdotool type --delay 50 --clearmodifiers "1ドル"
xdotool key Return
# Optionally, you can send more commands by adding them as additional arguments
# for arg in "${@:2}"; do
# xdotool type --delay 50 --clearmodifiers "$arg"
# xdotool key Return
# done

@asjur @ndom91 (and anyone else with Wayland issues) From #4240, there's the WARP_ENABLE_WAYLAND=1 environment variable that might work for you.

I'm having the same result...I guess it's not working on Kali for now.

Maybe is something about a privacy matters.. after all Warp need a login, so i was thinking perhaps they actully get more than just a
' login token ' of you system and Kali or Parrot is quite an experience in that matter .
just a random thoughts; after tring it on Debian and Fedora.

- warp is running successfully on wsl2, but rendered blank/black when launched to xlaunch
- I dont know what the hello screen is but pressing enter takes me to https://app.warp.dev/logged_in/remote?is_user_new=false&scheme=warp&public_beta=true and i see "Logged in as....", thats how i know warp is working (+ logs)

I feel like its one step away from working
any thoughts @alokedesai ? ☝️

@alokedesai any thoughts/revelations ?
would be super apreciated
Thanks and all the best!

will someone try to make it working on wsl2 alpine @fire17 ? :D

ARM linux versions are now on the Warp download page. https://www.warp.dev/download!

And note this is wayland with 150% scaling, no flickering or weird artifacts so far.

Ok, doing this solved the problem:
echo WARP_ENABLE_WAYLAND=0 >> ~/.config/environment.d/envvars.conf

I'm not sure there's a built in way (yet?), but this might help in the interim.