beefbroccoli

I've been a Linux user since 1995 and run Windows + WSL2 on my desktop machines. It's not too deep and pretty similar to why so many folks were drawn to Macs; a no brains just works GUI with the ability to launch a terminal and do real work on a UNIX-like system.

I can use a single machine to do everything I need, without rebooting and without making sacrifices.

I can watch Netflix and play games, without needing to write a f'n shell script to fix the screen tearing present in the nvidia driver - or realizing a particular game has quirks or doesn't work in Proton, so I just have to throw up my arms and say "Well, I guess we just don't play that game".

I can pop open a terminal anytime and have access to a real Linux system, as opposed to the faux "uncanny valley linux" solutions like Cygwin and Git Bash that seem to work until they don't. And unlike a traditional VM there's no management involved; I open the terminal when I need it and close it when i'm done, just like a normal application.

If you want to remove a lot of unnecessary pain in your life, completely abandon the idea of mounting a host FS within a guest VM. Doubly so if they're different OS's/FS's and triply so if this a development VM.

I think most developers would be happy with a Thinkpad, if it meant they could use Docker without pulling their hair out.

Not quite. WSL2 dynamically uses resources as needed (`vmmem`), whereas a traditional VM requires allocating a fixed amount of RAM and CPU from the host machine.

No. A minimal initrd + kernel is virtualized. Both Ubuntu and Kali are containers.

The simple answer is that typically the software that keeps one tied to Windows is the type that wants/needs to be on metal.

Hardware passthrough does exist and I only expect it to improve, but we're still a ways from reaching "just works" level.

I did. But I also have Windows machines, in which I use WSL2. Granted, I don't use GUI applications on them (or see much need to).

It's actually quite nice to have a "real" linux instance available on virtually any Windows machine. I believe Microsoft is targeting the "developer who uses a Mac" market share with WSL2 and I expect more and more to jump ship, as the experience is significantly better.

WSL2 uses it's own init system - only one kernel (plus a tiny initrd) is virtualized by hyper-v; each subsequent linux instance (distribution) is containerized. There's additional facilities that handle resource allocation dynamically vs the user specifying a static amount during VM creation.

These (and more) result in the end-user interacting with WSL2 the same way they would any normal application. To think of it as simply a VM isn't quite correct.

Living in Middle of Nowhere, New Mexico I was actually pretty surprised by how well Google Maps has worked. It knows my dirt/gravel roads pretty well.

You said earlier that "If the inconvenience of arguments troubles you, write a wrapper". That's precisely what a script like this is. A wrapper. I can run one simple, static command, similar to just about any build tool e.g. `cd project && make`.

It's unnecessary complexity for the user. As opposed to simply having the build instructions as `Run bin/build` you're suggesting "Run bin/build <project root>". But there's zero reason for requiring the user to supply the project root when we already know it.

Yes, it is silly. You've just added extra complexity to a project for little to no benefit. If you decide to move the script you take the same steps as if you moved anything else i.e update the references.

little one liners like that are arguably better implemented as aliases

In many cases one might not want a full stand-alone program with arguments, usage and such. Rather a "script" i.e. something that can be simply executed to run a series of tasks. For example it's quite silly for a build script to require the path of the project it resides in.

WSL2 is great if you treat like a linux system i.e. don't do goofy things like check out code on NTFS and work on it from Linux.

People talk about idempotency, as if it's complicated because it's a 5 syllable word.

  if ! which sometool; then
    install sometool
  fi

That's an idempotent shell script, in all it's simple glory.

I revisit these tools every so often and I still don't understand how they're any better than simple shell scripts.

Anyone else think this is just a clever ad for DigitalOcean?

I knew a guy in high school (1997) who was talking about this thing called Linux. It was a super complex operating system and didn't even have a graphical interface. Our thinking was if we managed to install it we'd be geniuses or something. After a few days we got it installed on his PC, but i'd yet to install it myself.

Unfortuantly the only computer I had (not counting the family PC) was a laptop with 4MB of RAM (effectively less than 4). The installation required booting one floppy disk containing the kernel, then swapping and loading another disk containing the installer. And course the machine ran out of memory during this process. I spent days learning how to compile a custom kernel that excluded the things I didn't need, until it was small enough to fit in memory and succesfully install it.

I think that's when I got hooked.

WSL2 has been a major game changer for me. Being able to isolate my work entirely inside the linux VM (with VSCode Remote) has eliminated 90% of my frustrations with developing on Windows.

It always gets a groan out of me. They come across as self-serving, like big corporations that run commercials to talk about how great they are ('we here at widget company X care about Y').

In comparison, the charity-ware of vim is fine to me. It does what it's supposed to without all the backpatting.

i've worked with way too many programmers who were great at math but couldn't match their shirt and pants.

haven't had that issue for years with npm/yarn, thanks to lockfiles.

Not sure. Maybe time to convert some classes to modules.

In typescript I will for example make a class called 'Tools' with static 'free form' functions and no constructor. I do it just because it's easy to organize, import and call the functions. Is this bad?

If I advocate for criminal activity and my advocacy is likely to produce said criminal activity, that speech is not protected.

By the context it's clearly in response to others giving OP flak. That's why he put "real developer" in quotes, as a dig at anyone who might presume a "real developer" would have no use for this kind of solution.

> Try to push as much logic as possible to the server. If the front end weren’t super complex, I would consider something like Phoenix instead which actually pushes everything to the server.

Sometimes you don't have or don't want a server, but still want to avoid the issue of wedding business logic to the UI.

With web apps my strategy is to treat business logic as a separate library housed in the same project. I'll have a "SomeBusiness" directory and just import it across the project like I would a third party library.

I remember the 90's. It was the era of "Best viewed in X version Y".

Git Bash on Windows. Things like this were always possible, but none of them made the install as quick and painless. This has been especially useful in Linux+Windows shops. You can simply state a requirement of "Windows users: Install Git For Windows", after which you can script things more less identically across both OS's.