Why use Linux instead of Windows?

I use Windows for most of my work, though since I have been using the Rpi boards, I have conceded that Linux is not as bad as the old Unix OS I avoided like the plague.

Over the last few years I have seen a convergence in IDE formats that make it more easy to move back and forth between the environments.

As others have said, for software development, you probably want to stick with the same environment that the final product will reside.

Cross platform issues will always exist.

As for the old Unix, I can tell you many horror stories.

I sent a team to Australia, after we had told them the specific system configuration they needed for our software.

The team arrived, four that the Australians were using something else.

They did their best to get it installed, but finally handed them the software, told them that if they ever get the right environment to install it and give them a call.

I also listened to one of the head Astronomy professors at the University of Arizona who swore he would never develop another software tool on Unix because every 6 months, everyone of his users got a new Unix update and his team had to do hundreds of modifications to get things working again.

But then I can also point to issues similar issues with Windows base software.

Though we could run our software on multiple Windows releases without problems.

I tend to find that anyone who peppers their response with "Windoze" or "Micro$oft" is rarely adding to the discussion and just wants to tell everyone what their personal allegiance is.

By the way, before you label me as "the enemy", I'm currently preparing a presentation for my mostly Microsoft stack development team on the benefits of getting their .NET code for running on Linux - mostly Pi and BeagleBone for our use cases.

It sounds like in your particular case you're currently using Windows and the software you want to use runs happily on Windows. There's likely to be no reason for you to switch to Linux. There will be a learning curve that's just not necessary for you right now.

Source?

The work on my own equipment is my freelance work for smaller clients who can't provide the appropriate equipment.

In my career, I have discovered there are two categories of IT departments.  Some see their mission as "Enablers" to make sure the money-producing parts of the organization have everything they need.  Those are a good indication of a well-run and prosperous company.  The other category are the "Gatekeepers" who see their mission is to protect the company's assets at ALL costs, even if it means shutting down the money-producing parts of the company.  These are a good indication of an autocratic and poorly-run company.  Most have even off-shored their IT, which makes absolutely NO sense given the security concerns!  These groups tend to have also bought into the Microslop lock-down mentality.  They're even to the point where I can't attach a removable drive to the laptop to transfer a boot image to an embedded device I'm testing.

There needs to be a balance between the two, especially where engineering teams are involved.

Sadly, more and more companies are going the "Gatekeeper" direction.

The question often translates to 2 other questions:

1. Which development tools will provide the shortest time-to-market with a suitably stable product and an appropriately sexy user interface? The tools may include much more than just compiler tool chains if you gave to worry about graphics editors, animation creators, audio editors, databases, communications and AI tools. etc. 
2. Which tools will end up costing less to develop and support the end product.

As others have mentioned the answer to both of these questions can be swayed by which tools your development team is familiar with.

This matches closely with what my company does.

Developers can build software on their personal device, for develop, test and debug purposes. But the deployable software is built with build services, based on assets that are checked into source control.

IDE and OS dependencies, except exceptions , are not to be checked in.

If you're building firmware that will be released in a product, on your desktop or laptop PC as a sort of personal build server, or on your own DIY Linux installation then that's a complete mess.

Give the problem to the IT team (or the engineering support team if that exists in the org), it's their whole purpose in life to meet the computing needs for you to do your work. Installing the build tools on some random PC setup is not easy to replicate, when people move on or if an old project needs to be revisited and the re-built firmware image looks slightly different. Once you have a dedicated build environment (whether that is a physical machine or virtual, whether it is Linux or Windows), properly maintained and backed up! then you're completely free to code on whatever OS you feel comfortable with (and whatever the IT team is willing to support).

I agree with those who say you have to know and use both Windows and Linux.  Many apps only run on Windows, Altium for example. Windows 11 is a very good operating system.

When it comes to developing logic and software for Xilinx chips, I prefer Linux.  I have been told that Xilinx develops their tools on Linux and then ports to Windows.  I prefer Linux for scripting and command line interface.  I often run Linux on my Zynq chips and the desktop Linux skills transfer right over.

I like to have two completely independent SSDs in my machine. One has the company required Windows OS and the other has Ubuntu Linux. I select between them in the UEFI boot menu. This works out well if I need to move to another machine. I can just pop out the Linux drive and put it into another machine.  Some guys even use an external SSD for Linux, so they don't have to mess with the company supplied Windows installation.  This can be a nice way to start since you may not have to ask permission from anyone.

Good luck,

dyessgg said:

I do Linux kernel driver/BSP development. 

That is indeed way different than what the OP wants to do: FreeRTOS on embedded processors.