WSL VS garden

It absolutely 100% can be true.

As an example: Windows Services for Linux 2 used a special init daemon to interact with the host OS.

That meant no systemd. That meant that the `systemctl` program wasn't there.

This baffled legions, armies, of wannabe sysadmins.

https://stackoverflow.com/questions/55579342/why-systemd-is-...

https://superuser.com/questions/1785697/systemd-in-wsl-on-wi...

https://github.com/microsoft/WSL/issues/9477

https://askubuntu.com/questions/1132230/unable-to-run-any-sy...

People on the whole have no idea how this stuff works, and they just copy magic incantations from StackOverflow to get stuff to happen. If that doesn't work, then this OS is broken. The end.

For these guys, WSL was broken.

Result:

MS hired Lennart Poettering.

https://www.theregister.com/2022/07/07/lennart_poettering_re...

He "fixed" it. Systemd now works in WSL2. All those guides for noobs now work. Everyone is happy.

In a world where tools like Flatpak and Snap are proliferating and it's driving deep divisions between Linux distros, if you think the average person struggling with Linux is going to use `ldd` to work out where the dependencies for something live, I'm afraid you are a deep guru who lives on a different plane of existence.

We now have widely-used packaging systems which simply embed an apps entire dependency tree into a package to avoid people having to work out the difference between `apt` and `rpm`. Thousands of terabytes of disk are being burned to make this stuff go away.

Yes, this is too hard. Way too hard.

Better source: https://github.com/Microsoft/WSL/issues/873#issuecomment-425...

One of the bugs where on the Docker side. As I have said, there have been several since release with a lot of impact period overlap. The latest and greatest is not resolved.

It's the issue of abysmal I/O performance in communication between the mounted WSL2 virtual hard disk and Windows mounts inside the WSL2 distro.

I found this github page and I was able to reproduce this from the answer

* Docker engine and not Docker Desktop in a VM. WSL2 works well after some configuration: https://github.com/microsoft/WSL/issues/6655#issuecomment-11...

Seems to more of a Defender issue than a WSL one, see https://github.com/microsoft/WSL/issues/8995

After adding exclusions for the fsnotifier-wsl process and and both variants of the WSL distro path my disk performance was improved.

Adding the idea64.exe process also helped since I was trying to run IntelliJ against projects inside WSL.

Hey there! Have you tried garden.io for caching? We also cache tests. Pretty much anything that's possible to cache. We're open source at https://github.com/garden-io/garden

To add to what's already been said: If you think about it, CI pipelines are typically a complete description of how your system is built, tested, and deployed.

Which is pretty fantastic except for how walled off they are. You can't really re-use these descriptions for e.g. development, they're not vendor agnostic, and they only way to run them is by pushing your code.

Maybe it's a silly analogy but it's almost like being a web dev that doesn't have a browser and needs to send their code to a friend who can tell them if that font size looks good.

I think we're way over due for freeing these "blueprints" of our system from the confines of CI and making them portable and flexible. And containers are the technology that's enabling that.

Full disclaimer (as always): I work at Garden[0] where we're also solving that problem but taking a slightly different approach to Dagger (it's still a DAG). Garden config is declarative and the jobs (we call them actions) have a semantic meaning. You can e.g. have a Build action of type container or a Deploy action of type Helm and Garden will figure out what to do with it.

[0] https://github.com/garden-io/garden

Yes, there's us over at https://github.com/garden-io/garden! We're big believers in pipelines that run anywhere. I even made a short little video that should give you the gist. [1]

Some of the short-list of differences: we use YAML for our configuration language, Dagger can use full-fat languages to define its pipelines. Our feature scope is broader: you can use us to vend IDP-like stacks to your developers if you're a Platform Team; we make development with remote Kubernetes clusters very easy, including all the remote image builds; and we have a number of integrations so you can bring your IaC tool of choice (Pulumi, Terraform) into your pipeline and set up service -> infra dependencies.

[1] https://www.youtube.com/watch?v=JFnan6s2cDg

Me too. In fact Garden (dev tooling for the Kubernetes)[0] is a Berlin start-up with three Icelandic founders.

And if I'm not mistaken, two of us worked briefly with @halldorel (above commenter) at an earlier Icelandic start-up. It's a small world (if you're Icelandic).

[0] https://garden.io

There are dedicated tools just for that. Apart from skaffold check also tilt.dev, garden.io, devspace.sh, okteto.com

Would appreciate any insights on garden.io. Thanks.

Telepresence, tilt, garden.io, okteto, skaffold etc.

- https://garden.io/

haha, do my pictures give off a strong not-web-dev vibe? Either way your right, I'm focusing on devxp and automation for kubernetes. Because my work is open source you can see it here https://github.com/garden-io/garden (btw we're also hiring another open core dev like me)