301–310 of 420 posts
I am giving up. WSL1 was a great invention but Microsoft gave up on it, either because of the filesystem performance problems or because of the debuggers. https://github.com/microsoft/WSL/issues/2028 (lldb, rr, delve all affected). This looks like a dreaded case of the first 90% is easy, it's the second 90% that is hard. Imagine implementing a translator for a vast majority of Linux syscalls just to find certain flav…
Is there a shell+terminal+font combo that folks really like for WSL? I've tried the new terminal beta with zsh and--for reasons I can't quite articulate right now--it feels "off" and I invariably proceed to boot up virtualbox for my debian, i3, kitty, fira code setup to get work done. Maybe it's the break in filesystems and $HOME? Edit: learning that WSL2 does away with the syscall-translating tech and mandates Hyper…
Screenshots of my terminal and set up are in my dotfiles https://github.com/nickjj/dotfiles.
It looks exactly the same as xterm on my native Linux laptop.
I've even gone as far as running i3 through WSL1 / wsltty and it worked very well with 1 monitor. I stopped using it because I have 2 monitors, but if I had 1 monitor it would have been usable for day to day development.
WSL2 is a fantastic product. The ability to debug python code on ubuntu and alt-tab to Steam is unparalleled. However there is a fundamental issue - Microsoft is treating this as a toy project. The number 1 problem is that the file system inside an Ubuntu shell/wsl2-container is sitting inside a hidden file system. It is is not exposed to the rest of windows and neither to backup tools like Dropbox, etc. So you have…
I think this is not correct. You can go to \\wsl$\ and it shows each wsl install as a network drive.
In linux, you just have a separate /home partition . You can have a dozen operating systems, merrily using the same home partition. you can trash your OS, but your home directory doesnt get trashed.
i have a pending request to offer the concept of a "home directory". the filesystem on which i work inside wsl2 should not be opaque to the rest of the operating system.
In WSL1, running "wsl git status" on a moderately sized repo on an NTFS (Windows side) drive or SMB file share is nearly instantaneous. In WSL2, running the same command takes over 30 seconds. WSL2 is a massive hit to the seemless experience between the two operating systems with filesystem performance from Linux to Windows files orders of magnitude worse. Yes, unzipping tarballs or manipulating and stat syscalls are…
Also, IO performance of WSL1 wasn't exactly great either compared to native linux filesystems.
In WSL1, running "wsl git status" on a moderately sized repo on an NTFS (Windows side) drive or SMB file share is nearly instantaneous. In WSL2, running the same command takes over 30 seconds. WSL2 is a massive hit to the seemless experience between the two operating systems with filesystem performance from Linux to Windows files orders of magnitude worse. Yes, unzipping tarballs or manipulating and stat syscalls are…
My git status/add/commit/push cycle has gone from seconds to minutes in length. It's unbearable and I'm going to abandon wsl as a result. Shame, it was really good.
The supposed speed boosts of WSL2 requires having your files living directly inside of WSL2's file system.
I haven't tried WSL2 yet since I'm waiting for it to hit stable.
Earlier quoted context omitted.
But what's the point of that? If I wanted my files to be on Linux I'd use Linux. I'm on Windows exactly because of things like this: the ability to use proper UI tools like Explorer to manage my files. How do I do that with WSL2?
Go to \\wsl$\ and it mounts the WSL instances as network drives.
I mean, not hating it, but that doesn't feel all too straightforward, definitely less sonthab wsl1 :/
Earlier quoted context omitted.
Windows with git and its bash installed works surprisingly well for node development. Docker doesn't work on either MacOS nor Windows, right?
Windows has direct docker support and has had it for a while. Not sure how great, not into containers myself ;)
I've been running this set up for over a year and the volume performance is superb.
Flask, Phoenix, Rails and Webpack driven apps are all a fantastic experience. For example Webpack takes 150ms to compile SCSS / ES6 JS diffs for large real world projects. Web server reloads on code change are effectively instant and I get microsecond response times in some Phoenix apps in development.
This is on 6 year old hardware too and the source code isn't even sitting on an SSD (but Docker Desktop is installed on an SSD).
In all cases, everything is running in Docker through Docker Deskop and I use the Docker CLI / Docker Compose in WSL as a client to connect to Docker Desktop.
It's all documented at https://nickjanetakis.com/blog/setting-up-docker-for-windows....
Earlier quoted context omitted.
My git status/add/commit/push cycle has gone from seconds to minutes in length. It's unbearable and I'm going to abandon wsl as a result. Shame, it was really good.
You can convert WSL2 to WSL1! There's an argument to wsl.exe you can use to go back. Do it, free yourself (and your kernel)
In WSL1, running "wsl git status" on a moderately sized repo on an NTFS (Windows side) drive or SMB file share is nearly instantaneous. In WSL2, running the same command takes over 30 seconds. WSL2 is a massive hit to the seemless experience between the two operating systems with filesystem performance from Linux to Windows files orders of magnitude worse. Yes, unzipping tarballs or manipulating and stat syscalls are…
If microsoft implemented the host side of virtio-fs then the guest could make use of that. Also, IO performance of WSL1 wasn't exactly great either compared to native linux filesystems.
In WSL1, running "wsl git status" on a moderately sized repo on an NTFS (Windows side) drive or SMB file share is nearly instantaneous. In WSL2, running the same command takes over 30 seconds. WSL2 is a massive hit to the seemless experience between the two operating systems with filesystem performance from Linux to Windows files orders of magnitude worse. Yes, unzipping tarballs or manipulating and stat syscalls are…
My guess is they people who put it together were under the assumption that Linux should be as simple as to implement as the old Windows Subsystem for Unix and POSIX API.