Has worked since .... forever. Interestingly, it works with WSL2 on windows, too!
For one thing, Docker is not really "Linux inside Linux". It uses Linux kernel features to isolate the processes inside a container from those outside. But there is only one Linux kernel which is shared by both the container and its host (within the Linux VM, in this case).
For another, running Linux containers in a Linux VM on Windows is one (common) way that Docker can work. But it also supports running Windows containers on Windows, and in that case, the Windows kernel is shared just like in the Linux case. So Docker is not exactly "Linux tech".
It's Docker Desktop what assumes WSL; Docker engine does not. Also, you seem to need Windows Server; IDK if it can be made to work on a Pro version.
[1]: https://learn.microsoft.com/en-us/virtualization/windowscont...
That said, work is a strong word; Windows containers in general are pretty jank.
With the former a Linux kernel is required. You have two options: using WSL2 and benefiting from all the optimizations and integrations that Microsoft made, or running a full Hyper-V VM that gives absolute control and isolation from rest of the system.
For the latter, you need a Pro license and need to enable Containers feature (deployment requires more expensive Server licenses). Then you can run slimmed down Windows images like "nano server" which doesn't have GUI APIs.
Running Linux containers using Docker Desktop has a small Linux VM in which the containers are run and then Docker does some mucking about to integrate that better with the Windows host OS.
I desperately wish I could run docker properly (CLI) on the Mac rather than use docker desktop, and while we are making a dream list, can I just run Ubuntu on the Mac mini?
https://github.com/apple/container
I've been experimenting with it in macOS 15, and I was able to replace Colima entirely for my purposes. Running container images right off of Docker Hub, without Docker / Podman / etc.
(And yes, it is using a small Linux VM run under Apple's HyperKit.)
I’m surprised I didn’t stumble into any of these options, I searched and didn’t find.
WINDOWS_IP=$(ip route | awk '/^default/ {print $3}')
DISPLAY="$WINDOWS_IP:0"
Now I can use the mighty mobaxterm from https://www.mobatek.net to just run whatever and pipe it back to Windows.
One caveat is that the $PATH gets polluted with space characters by 'Doze, so I have to do something like this for QGIS:
PATH=/usr/local/sbin:/usr/local/bin:/usr/bin qgis -n &
What are your use cases? To run Linux GUI apps?
Does mobaxterm allow you to view those GUI apps?
Are there benefits running it under Arch and then 'stream' it to Windows?
Assuming it's faster running QGIS in Linux? Or is it because all your other dev stuff is in Linux?
(Sorry of these questions are basic - just curious).
WSL2 provides a GPU accelerated Wayland server. If your Mesa build (ver > 22) has d3d12 drivers you can use Windows DirectX as your OpenGL driver. Combined with the WSLg Wayland server you get near native desktop performance out of GUI apps.
So I had to install USBIP on the Windows11 host, and bring in a tool chain and compile a Linxux 6.x kernel in order to add external storage for my QGIS data.
My clients are a rpi 4 and an older ipad. Sometimes use an Android phone as well.Works really well.
On one hand, it made me chuckle a bit. On the other hand, it could be reasonable in many scenarios.
check into tailscale or cloudflare tunnels/argo
I've also done xpra in docker before; that's always felt as hacky as it sounds though.
It worked but Android killed it mercilessly if it used too much memory or the rest of the system needed it.
Kinda hope they revisit this idea in a near future again
https://www.androidauthority.com/android-16-linux-terminal-d...
You can connect mouse, keyboard, and display to the Android device through an unpowered USB-C hub that offers the respective ports. Battery life depends on the make/model of Android device.
I have a Motorola phone and the experience is very nice.
[0] _ https://uperfect.com/blogs/wikimonitor/list-of-smartphones-w...
It works perfectly with GrapheneOS as of Pixel 8 and newer.
I searched for the term and it seems to be a DIY kit to do reinforcement learning to try to crack WPA keys?
I was just wondering about the comment that it can be carried around on a keychain.
Looking at the pictures, some have a little screen attached and maybe a battery, so thought it might be a bit too big for a keychain.
https://www.thingiverse.com/thing:6981256
The pwnagotchi stuff is fun, but its also easily turned off, which means its not always just pwnagotchi'ing .. more of a battery powered raspian box I can also clip inside the moped glovebox .. When I get to my desktop, I can also just use standard KVM dongles and use it that way .. its not fast, but for a lot of things, its quite adequate ..
Sounds like a fun little project.
Going OCI here only makes sense for temporary, disposable sessions.
Seems very inefficient to have to render everything through the browser
Which has Xwayland support. You can still run X11 apps.
The desktop is accessed locally and not via a network connection and it's running under Xwayland.
These days I have a Docker container with Remmina that I use as a bastion (fronted by Cloudflare and Authelia for OIDC), but everything else is LXC with xrdp and hardware acceleration for both application rendering and desktop streaming (xorgxrdp-glamor is much, MUCH better than VNC).
I am, however, struggling to find a good way to stream Wayland desktops over RDP.
Apart from a handful of games, I haven't actually needed Windows for anything. So I'm curious—what Windows-only software is keeping you on it, OP?
But for everything else I’m on linux as well.
At that point I switched back to windows but I’ll try again after a few months. I always keep trying.
I think if I didn’t play games I’d be fine with Linux. I hate Windows except that everything just works.
Granted it helps that a lot of the time I need "advanced" debugging relates to msvc/windows specific issues, which while I could run it in wine, it's just easier if I'm on windows anyway.
Still, I caution people to not just jump to Linux. The actual very first problem is not software. It's hardware. Firstly, running cutting edge motherboards and GPUs requires a more bleeding edge setup than typical LTS distros give you; you'll be missing audio codec drivers and the GPU drivers will be missing important updates, if things even boot. Secondly, NVIDIA GPUs are currently in a weird place, leaving users with trade-offs no matter what choices they make, making it hard to recommend Linux to the vast majority of users with NVIDIA GPUs. Thirdly, and this one is extremely important, nobody, Nobody, should EVER recommend people run Linux on random Windows laptops. This is cruel and unusual punishment, and it's a bad idea. It's a bad idea even if Arch wiki says it works pretty good. It's a bad idea even if a similar SKU works well, or hell, even if a similar SKU ships with Linux out of the box. It's just a bad idea. The only two big vendors that even really do a good job here are System76 and Framework, and they still have to use a bunch of components from vendors that DGAF about desktop Linux. It is impressive that you can more or less run whatever desktop hardware and things usually work OK, but this logic doesn't apply to laptops. This point can't be stressed enough. I have extensive experience with people trying to switch from Windows to Linux and it's genuinely a challenge to explain to people how this doesn't work, they don't have the frame of reference to understand just how bad of an idea it is and learning the hard way will make them hate Linux for no reason.
Still, even with good hardware, there's plenty of software woes. You'll be missing VSTs. You might have to switch to Davinci Resolve to edit video, Krita to do digital painting, and Blender to do... Well, a lot of stuff. All good software, but a very non-trivial switch.
I'm really glad to see a lot more people interested in running Linux and I hope they have a good experience, but it's worse if they have inflated expectations of what they can do and still have a good experience with. Being misleading about how well Linux or WINE will work for a given task has never really helped the cause, and probably hurt it a lot.
I won't argue about Proton/Steam, though, that shit's miraculous. But honestly, a lot of people like playing competitive multiplayer games, and those anti-cheat vendors don't give a damn about your Linux, they're thrilled to start integrating Secure Boot with TPM attestation as it lets them try to milk more time out of the "maybe we can just secure the client" mindset. (I personally think it's going to die soon, in a world where ML has advanced to the point where we can probably do realtime aimbots that require absolutely no tampering with the client or the computer it runs on, but we'll see I guess.) But for me who doesn't care, yep, it's pretty good stuff. Whenever there's a hot new thing out chances are it already works on Proton; been playing a lot of Peak which was somewhat popular in the last couple months.
The most significant issues:
- Peripherals simply don't work at all, as in, no touchpad or keyboard, or at least no touchscreen. This is definitely an issue with a variety of laptops including some Microsoft Surface and Dell laptops.
- Power management. Frequently, machines fail to sleep or resume reliably.
- Audio is low quality and quiet. This problem was publicized pretty well by the Asahi Linux project, but it is far from unique to MacBooks: a lot of laptops now require OS-level audio processing to have good audio quality. Even my Framework 16 partly has this issue, though it can be alleviated partly with a BIOS option. I believe this also impacts some System76 laptops.
- WiFi/Bluetooth instability. This issue is probably worst with some Realtek radios, but I've also seen it from time to time with Mediatek.
- Sometimes, issues booting at all. Yep. Sometimes it just won't boot, as sometimes the kernel will just break support, and maybe unbreak it later. That's the nature of just running random shit, though.
I think that illustrates enough so I'll stop there, but also don't forget the hurdles to even get started. Often times the very first thing you want to do is disable secure boot which differs a bit per system. This isn't always truly necessary, but even if you're using a Linux distribution that works with Secure Boot it's often a good idea, as there are a variety of things that you can't do easily with Secure Boot on Linux.
Older laptops are less of an issue since Linux tends to get a lot more mature with older hardware as time goes on, but it's still a little hit or miss, especially with vaguely recent laptop hardware that has weird stuff like Intel IPTS. But that having been said: Linux doesn't support old hardware literally forever, either. Old hardware sometimes stops working and gets pulled from the kernel, or moves out of mainline Mesa, and so forth. So even that isn't a 100% panacea.
One place to check is the nixos-hardware repo for machines with reasonable support.
> to provide an anecdotal counter-example, the Asus Zephyrus, Flow and ProArt lines run pretty well on Linux provided you replace the Realtek WiFi.
I should be very clear here: what I'm trying to caution people not to do is set people up for the expectation that random Windows laptops will run Linux well. Specific Windows laptops absolutely do run Linux well sometimes, just by virtue of using parts that are very well-supported and somehow having firmware that isn't full of 100,000 bugs. (I love Framework but there are some occasional issues i have with my Framework 16 that really seem like they can only be issues with the firmware rather than Linux.)
That said, I still think you should consider tempering what you tell people, especially people you don't know well. The vast majority of users are not the type of people to disassemble their laptop and replace the WiFi card. And while I don't doubt what you're saying is true, I also think it's important to note that laptops vary a lot from SKU to SKU and revision to revision; the vendors typically don't support or test Linux, so there's absolutely no reason they wouldn't break it in a minor revision of hardware or firmware, either. Telling people that ThinkPads generally work well on Linux isn't necessarily unfair (They usually do, even today) but it's not as much of a sure thing as everyone portrays it, there are exceptions. And also, when you say they run "pretty well", you may have more reasonable expectations for what "pretty well" means than the average person. For one thing, I've found that the average person simply lacks the creativity to imagine the ways in which operating system compatibility issues can manifest. For another, these minor usability problems can profoundly impact how one uses their computer. For example, if sleep/resume works 99% of the time, that's actually not great. What happens in the remaining 1% of the time, you lose all of your work unexpectedly? Does your laptop melt inside your bag? Maybe, if you are profoundly unlucky, it could even light your damn house on fire. Of course, Windows and Windows laptops have plenty of problems with sleep/resume these days too with no Linux involved, but I still believe strongly that users who have never experienced broken sleep/resume will have a really bad time here. And again, since these laptops only support Windows, any random kernel or BIOS update could kick things into a bad state. (Immutable OSes will at least save you from having to guess, but I use NixOS and sometimes my intermittent hardware issues are really hard to pinpoint, which is observable for anyone who looks at the history of kernel versions on some of my less Linux-friendly devices.)
I think people evangelizing open source and Linux are very well-meant and often times manage to really help people escape the abusive relationship they have with Microsoft, and I want it to continue. I just want people to be careful with how they message Linux on laptops. If you are really sure someone will be highly tolerant of working through problems, maybe you need to caution them less. But, for other people, I just think it's better to be very careful and fully not recommend laptop vendors that don't support Linux. These laptops don't work well with Windows by accident!
I pray you are right, I fear other bullshit excuses will be found though..
https://docs.linuxserver.io/images/docker-webtop/
These images are top-notch, well documented, and have recently been refactored to use Selkies under the hood. Even with gamepad support, I’ve used these for running DOSbox, RetroArch, streaming video, and many other things.
There’s even a mature extensibility layer for using their images as a base layer to add services and apps.
Can’t speak highly enough of the linuxserver.io folks.
I thought Docker images always run in a VM on non Linux systems, no? This guy is running Windows on host, right? Confusing
https://blog.jessfraz.com/post/docker-containers-on-the-desk... https://github.com/jessfraz/dockerfiles
https://github.com/aard-fi/tumbleweed-images/tree/master/way...
I use two different setups - on some systems I only run things like browsers in conatainers, on others I also run the desktop itself in a container. Not published yet are my helper scripts, that'll need some more cleaning up.
My idea was very similar, using TigerVNC and just launching Steam without a WM. Unfortunately I think I lost the code for it
You can get better performance and lower latency for your remote desktop and eliminate lag by using a gaming-focused remote desktop server, e.g. using Sunshine: https://github.com/LizardByte/Sunshine .
You will need to give it access to a gpu though.
It's had me thinking a lot about remote computing.
“After my failed custom image attempt, I found a promising XFCE-based Debian image on Docker Hub. I downloaded it in minutes and, with a few commands, launched it. When I opened the URL, I was greeted by a fully functional Linux desktop, running right in my browser. The pure geek joy of seeing a complete OS served from inside a Docker container was a feeling I won’t forget. It worked”
And on Windows, docker for Linux containers is just a VM, so this part isn’t really true:
“Containers are not isolated Operating Systems: Docker containers share the host kernel. This is what makes them lightweight and great for single services. Whereas desktop environments expect system services like (systemd, logind, udev, DBus) and device access to be available. Containers don’t provide that by default
The container runs KDE a web browser that runs an emulator. It's all GPU accelerated.
https://github.com/selkies-project/docker-selkies-glx-deskto...
> The created container will be tightly integrated with the host, allowing sharing of the HOME directory of the user, external storage, external USB devices and graphical apps (X11/Wayland), and audio.
> Why * Provide a mutable environment on an immutable OS, like ChromeOS, Fedora Silverblue, OpenSUSE Aeon/Kalpa, or SteamOS3 ... * Provide a locally privileged environment for sudoless setups (eg. company-provided laptops, security reasons, etc…) * To mix and match a stable base system (eg. Debian Stable, Ubuntu LTS, RedHat) with a bleeding-edge environment for development or gaming (eg. Arch, OpenSUSE Tumbleweed, or Fedora with the latest Mesa) * Leverage a high abundance of curated distro images for docker/podman to manage multiple environments.
> Aims This project aims to bring any distro userland to any other distro supporting podman, docker, or lilipod. It has been written in POSIX shell to be as portable as possible and it does not have problems with dependencies and glibc version’s compatibility.
> It also aims to enter the container as fast as possible, every millisecond adds up if you use the container as your default environment for your terminal:
> Security implications Isolation and sandboxing are not the main aims of the project, on the contrary it aims to tightly integrate the container with the host. The container will have complete access to your home, pen drive, and so on, so do not expect it to be highly sandboxed like a plain docker/podman container or a Flatpak.
distrobox create -n test
distrobox create --name test --init --image debian:latest --additional-packages "systemd libpam-systemd pipewire-audio-client-libraries"
distrobox enter test
Unfortunately it looks like sandbox mode [0] is not a goal, so it doesn't solve the main problem I have - running semi-trusted apps (e.g. Android Studio) and minimising their impact. Currently I just share X11 socket and run it in Docker.
> No reboots, no separate partitions—just a seamless, containerized Linux desktop.
> Windows 10 PC .... No reboots
You're kidding right? Linux is no reboots, Windows... Well let's just say yet another reason I no longer daily Windows.
This allows me to sandbox my whole environment so i can run it exactly the same no matter the machine, including all packages and editor plugins.
If anyone wants to check it out it's at https://github.com/hauxir/dotfiles
the devenv.sh file describes my entire environment.
k_bx•5mo ago
craftkiller•5mo ago
[0] https://wiki.archlinux.org/title/Systemd-nspawn
k_bx•5mo ago
k_bx•5mo ago
However, the bootstrapping process is so much work that I've ended up ditching it for now. I don't want to "automate the automation" yet.
Trying out podman now.
ranger_danger•5mo ago
k_bx•5mo ago
Seems a bit less popular and supported, I also like that Podman has strong backing from Red Hat and potentially seamless macOS integration.
Otherwise if Podman will fail I’ll take a look at Incus.
k_bx•5mo ago
Trying Incus now
throwaway74354•5mo ago
k_bx•5mo ago
On another hand, if ubi’s work fine — that means there should be no technical limitation to keep Ubuntu working.
I’ll keep playing with Podman for now, but will switch to Incus if that will fail
seabrookmx•5mo ago
nothrabannosir•5mo ago
cpuguy83•5mo ago
Build system packages and containers from those packages for a given target distro.
Behind the scenes it uses buildkit, so it's no extra stuff you need, just docker (or any buildkit daemon).