I wonder what drives people using Microsoft and then using more from this company.
We didn’t knew it better, back then. We knew it better, now. But migrating is work. So we prefer to suffer! And harm others! This Linux and BSD people are so annoying with their desire for compatibility. They shall suffer, too! And when we buy everything from a Monopoly, we don’t need to think.
Somehow. Part of the game is that you’ve always an excuse with Microsoft. You cannot made responsible? There is this quote about IBM:
Nobody Ever Got Fired for Buying IBM.
But I cannot remember stories about suffering from IBM forever.
From what I've seen in my industry? To pass all the liability to Microsoft.
"If something happens, we used enterprise grade industry standard software. We did our due diligence."
This outlook is basically why we can't innovate anymore.
I had to recently sit through a meeting where our CTO quoted all the "blogs" he's been reading as a way to slap down my suggestion for an in-house project.
It's why school boards don't do anything useful, among many many other things in our society. It's an endemic disease.
Most of the time it's extremely exaggerated, but it's trotted out and used as a CYA excuse almost immediately by most in the executive/managerial class. Both due to outright laziness and incompetence, and also as just a... why take any personal risk whatsoever making actual decisions with any impact if I can keep my cushy job and career rolling by being as milquetoast as possible.
Never mind you get the big bucks to make such important and controversial decisions at great personal (career) risk when some inevitably go wrong. Everyone forgot that part. Such roles should be hard, difficult, and risky.
They're using Microsoft because all of the alternatives have the same issues.
FOSS isn't magically immune to vulnerabilities.
It doesn't help that the FOSS community generally prefers the C programming language over more modern and safer alternatives as a cultural thing. The result is just as many vulnerabilities, if not more, per line of code or per feature. Keep in mind that SharePoint is an enormous product with a 3.6 GB ISO image used to install it. If you think anyone is able to develop that volume of server code and have zero vulnerabilities... I have a bridge to sell you.
Valid point about the image size. A possible sign for bloat? Bloat is danger.
Second:
C, C++ or Rust are our tools. Everyone prefers another for technical and personal reasons. A religious believe in salvation by the next programming language is not helpful and causing harm. I hope sanitizers for C/C++ improve further - which improved safety a lot. For C++28 or C++3x we can hope for further safety improvements. Which we need.
Most bugs are logic errors. SharePoint is - according to my knowledge - implemented in C#. The CVEs mention deserialization of untrusted data, improper limitation of a pathname to a restricted directory ('path traversal'), improper control of generation of code ('code injection') and so on.
I'm rather careful about people requiring another language and claiming it will fix everything. Reliability needs hard work (design, code, review, testing...more review) even with well selected tools. I guess Microsoft does that. And I guess Microsoft works like the rest of the industry, focus on time-to-market and building a monopoly in every area. That's why we see rapid updates in a lot areas and - worse - enforced updates. And why software is known for it's low quality in comparsion to other industries?
Examples:
GNOME opted to use JavaScript in the hype back in 2010:
* JavaScript reduced compatibility compared to C/C++.
* They suffered a lot from memory-leaks. Due to JavaScript.
* The run-time modification seems not to be a big benefit.
* Extra dependencies for JavaScript. More memory usage.
The code matured and it works now rather well. I didn't liked the decision back then. I don't like it now. But I also don't request a rewrite in C, C++, Rust or Python. Without good reasons (plural) it doesn't benefit the project.
Java also suffered. This rewrite of C++ to Java with JRE is a example, why rewrites for the sake of rewrites aren't a solution:
Rust has never been successfully used to develop large-scale software of the size of SharePoint, Exchange, or anything of that order of magnitude: gigabytes of compiled code with the main executable being 10s of megabytes in size.
An observation I've made about Rust is that because it eschews OOP, it tends not to "scale" to large development teams for single applications. It's great for CLI tools, small web apps, etc... but after some scale it runs out of steam.
This is exacerbated by its glacial compile times compared to other languages, even C++, let alone C#.
I just can't imagine something the size of SharePoint being developed entirely in Rust!
Think of an app like SharePoint as "Linux Kernel + Drivers + Userspace tools". There's a few large monolithic executables some tens of megabytes in size for each of the core web apps and services, and then hundreds file format converter plugins, database drivers, etc, etc...
Chromium is similar. It's practically an operating system now, it even has USB drivers! I had to compile Chromium from scratch once, for which I spun up a 120-core cloud VM with 456 GB of memory so that it wouldn't take all day.
With Rust... that would take all week even on that box.
I mean.. people contributing to FOSS generally program in what they know - i.e. I have some time to contribute, I'll spend 10 productive hours in C, because I know what I'm doing, vs. learning Rust only to spend 30 hours and not really getting anything done.
I contributed to a Tcl/Tk library that I was using at work that had a specific issue with some image files, so I fixed it internally, and contributed the fix back to the FOSS project (with permission from work).
People working at Microsoft in the SharePoint team also program in a language/framework they know (and they must be masochists if they're working with ASP.NET WebForms). Knowledge of the language doesn't prevent vulnerabilities.
