backslash_16

I agree it's totally worth it! I'm lucky that I have just enough free time to debug these things and I work with a few excellent Linux devs who have helped me with a few things.

Thanks for understanding the spirit of my point about the shortcomings above and I really like the way you phrased the "Windows has its issues as well, they're just different ones" - and I completely agree there.

With Windows you need to navigate the Microsoft account, files getting stored in OneDrive, updates happening outside your control (arguably a good thing for most users), and more that I'm sure I'm not thinking of.

I do think the Windows issues are more abstract like security, privacy, and default on features - while the Linux ones tend to be more in my face usability ones. Again agreeing that choosing your hardware and desk/laptop setup can alleviate many of things. But that requires knowing ahead of time and people switching in reaction to something Windows is doing don't get that benefit.

I guess I'm writing all this because the idea of a Linux distribution working perfectly on most/all laptops really excites me and I think being candid about the shortcomings yet providing support to the distributions is how we can get ace these fit and finish issues.

Food for thought for anyone else reading this - the end goal of Linux for everyone is why I don't get too worked up about snaps. If they get to a point where I can tell my mom she can safely install apps X, Y, and Z by pointing and clicking in the app center it's a great computing future.

In case anyone wants to point me in the right direction or give me some pointers, I’m a lifelong windows developer who switched to Linux (Ubuntu 24.04 lts) on my personal desktop and a laptop (I’m fully in on the switch) and it’s not great.

I think we need to accurately represent the shortcomings so people who switch aren’t surprised.

So far those are:

  1. Laptop - Battery life is bad compared to windows. It’s about half.

  2. Laptop - sleep doesn’t work. 

  3. All - multi-monitor setup with different pixel scaling doesn’t work for many applications.. unless you dig into all the Wayland options and issues and figure out how to launch all these apps under Wayland. 

  4. All - In general Wayland vs X issues. I can’t screen share with zoom. 

  5. All - Bluetooth driver issues - my Bluetooth headset won’t connect as an audio input and output device at the same time.

Now to be fair, I think all these are okay trade offs but they are a conscious choice. If you have anything outside a standard one monitor, wired peripherals setup you will probably hit issues you need to debug.

I started paying for Ubuntu pro to put my money into it, so I’m hopeful for these kinds of things in the long term.

I would love separate variable initialization vs assignment. I know that ship has sailed.

It's interesting, I never cared about that until I did "Crafting Interpreters" and realized how separating those two actions helps clarify scopes.

Being realistic I know it's too large of a breaking change and will never land in the language but I can dream right?

Thanks for the info. Using different containers for build and test vs the packaged app makes a lot of sense.

> easier if you don't have to worry about compatibility with the target environment.

I develop on Windows and deploy onto Windows right now, and as we get everything onto .Net Core (and maybe eventually) Linux I'm thinking the same thing. If I can build/test/run my app and service on the same target OS it can only make life better.

Any good guides for this or am I overthinking it and anything on containers will work?

I like Black and Pylance, which is backed up pyright. Pylance and VS Code for dev time analysis (even though it has a few annoying issues like auto-importing the wrong paths) and pyright for "build" and test time analysis.

I set black to a longer line length like 100 or 110 depending on who I'm working with. Black makes sure everything has consistent formatting.

One way to know if it’s a .Net client is you can run ILDasm or DotPeek against the windows binary and see if it decompiles it.