~/projs

I like ~/w or ~/p options

Vscode is installed on windows. Then you install vscode ssh plugin from Microsoft and open ssh connection from vscode to any Linux including WSL hosted Linux.

I am a software developer and work on Kubernetes based project.

I was given a Mac laptop when I joined. It was a few OS releases behind, because corporate IT didn’t support newer versions.

Macs have to run some sort of VM to do docker based development.

VMs are not that great.

When time came, I requested a Windows laptop. I installed Debian on WSL 2. Then got it to run systemd properly and installed Docker on WSL. Then vscode on windows host with remote ssh into WSL.

Vscode ssh integration is probably best least known feature of vscode. However, initial connection setup always requires tweaking to get that best experience.

By the way, official docker setup is through VM on windows. WSL is not a recommended route, but one can get it working.

This setup beats Mac any day for me.

I wish I could run Linux on work laptop, but corporate IT doesn’t know how to deal with it.

My wife complained that Mac got worse at searching samba shares.

Corporate support for Macs is usually worth than on Windows.

It is a very risky move.

Fedora atomic or not is nice.

I got tired of manually installing Arch and was pleased with Fedora the most.

I actually run away from Mac. Mac OS X is long time as not Linux.

WSL is a way better option than whatever VM option is on Mac.

I am happy with WSL as well. I don’t try to get Linux GUI running.

I use vscode remote ssh session. I run docker natively on Linux, not on windows.

The trick is to get DBUS services running in whatever flavor of Linux you install. Don’t try running a full UI session.

The biggest problem I have on Linux is time drift after laptop goes to sleep. it is easy to deal with manually.

Cargo is heavily used.

Your tutorial is the odd one.

I own old Chromebook.

Chromebook software updates are not forever.

It is my understanding that some Chromebooks might be locked in such a way that installation of Linux might NOT be an option or the might be a high chance of bricking the device.

At least that was the case with my Chromebook.

So, once OS updates are unavailable, the machine might become a weak link from security standpoint or stop running some software.

Chromebook is still a great option, but be careful with very old ones.

Preference order is: Fast IO like SSD and mirror RAID, then RAM size, then core count and then core speed.

This is not RUST specific.

Take snapshot. If problem occurs, manually change boot label to use snapshot label.

BTRFS is zero effort on root, because it is included in kernel. ZFS on root is extra effort at least on Arch, due to licensing restrictions.

Dedicated gaming machine or dual boot is a way to go.

I played steam on Arch and one update of OS and game stops working.

Despite claims, Windows gets better outcomes. I played a lot of World of Tanks Blitz and the same hardware on Linux was significantly lower graphics quality and FPS compared to Windows.

Windows is better for gaming than Linux.

With Linux you have to be ready to play only what works.

Great illustration.

Someone explained it to me this way:

If knife is a newest feature, then

• cutting edge has newest features
• bleeding edge bleeds from knife cuts, because it doesn’t have the newest features.

Any snapshot distribution by definition is on bleeding edge.

Any rolling release is by definition on the cutting edge.

I usually go for gnome regardless of distribution. I have old laptop that i use to try distributions occasionally.

Same hardware, same desktop, same encrypted drive, same BTRFS choice, different responsiveness at times.

Systems heavy on flatpak tend to be noticeably slower.

I had sluggish experience with SUSE. Updates were slow. Installation was very slow.

Starting apps was not as snappy.

Promise of snapshots was great, but not unique.

Overall slower than my regular distro experience killed it for me.

I simply asked myself: will it bug me every time I use the laptop? The answer was yes, and decided to end it.

Installer is a big part.

2nd biggest part is how system is configured.

Debian is not afraid to create its own version of default configuration. Take some mail software as example.

Arch on the other hand is most likely just going to ship original application configuration.

Debian might be nice and easy, until configuration change is necessary. Suddenly, original application documentation doesn’t apply. Debian documentation may be obsolete or absent. And that is the beginning of reading all of the configuration files. Normally, it is not a problem until something like email system configuration is necessary.

That’s when Arch philosophy of making fewest changes to software comes to shine. Original documentation usually works and applies well.