• 0 Posts
  • 7 Comments
Joined 2 years ago
cake
Cake day: November 13th, 2023

help-circle


  • I’ve used both. What I can tell you is that moving to WSL is like moving to Linux wholesale. Treat it like porting your toolchain.

    IIRC, MinGW tools will happily take windows style paths (e.g. “C:\Users~myuser\projects”). If your tooling/scripting depends on being able to use Windows style paths, you’ll have to fix that first or you’re going to have a really bad time. There may be other small differences between MinGW tools and what ships on Ubuntu (or whatever Linux you decide to use in the WSL).


  • dejected_warp_core@lemmy.worldtolinuxmemes@lemmy.worldWSL users
    link
    fedilink
    arrow-up
    4
    arrow-down
    1
    ·
    edit-2
    2 months ago

    All I know is that the WSL is a massive step-up from Cygwin or Mingw32. We’ve been here before. The most recent incarnation before WSL was a klunky VirtualBox VM steered by Packer. The idea that you can mash a few buttons and get an Ubuntu VM with filesystem mapping that “just works” is a huge improvement.

    Edit: I really don’t get the vitriol anyone gets for using the WSL when it’s a problem the FOSS community has tried to solve three times over in the last 25+ years or so.



  • Agreed, although it’s wise to have a backup option for this. It’s entirely possible that you have two solid Portal players go at this, which should be a really fun romp. However, in my experience, any skill gap between the players usually turns every stage into “how do I carry my friend through this puzzle?” An extreme version of this can be seen in Game Grumps’ playthrough.


  • I agree and disagree.

    The premise is solid: unify config so it’s standardized and machine parse-able for better integrations like an easier-to-build UI/UX. It could even have ramifications for cloud-init and older IaC tech like Puppet.

    The problem is Linux itself. Or rather, the subsystems that are cobbled together to make Linux a viable OS. You’re not going to get all the different projects to pivot to a common config scheme, so this YAML standard would need a backend to convert to/from whatever each little deamon and driver requires. This creates a few secondary problems like community backlash (see systemd), and having multiple places where config data must be actively synchronized.

    I think the current crop of GUI config systems are aleady well down the most pragmatic path: each config panel touches one or more standard config files, wherever they are, and however they are structured. It’s not pretty under the hood, and it’s complicated, but it works. These tools just need a lot more polish on the frontend.