6 ms·
Would anyone agree that complexity provides a foundation for insecurity while simplicity makes audits easier? Large software with many parts have more potentia
by loginusername 11y ago
Would anyone agree that complexity provides a foundation for insecurity while simplicity makes audits easier? Large software with many parts have more potential for flaws. Small software with few parts have less potential for flaws because they are easier to find and fix. Implausible? Well, I happen to believe this.
If Microsoft ever released the Windows source code, what would we find? Simplicity?
How easy would it be to audit?
Bias disclosure: I like small software. Windows and most all other software released by Microsoft is large, or packaged in such a way as to necessitate a large download/install.
- wvenable 11y agoAll software is large. If you break it into smaller pieces, it's still large. If you look into how iOS devices are jailbroken, it's usually combination of bugs from different pieces of smaller software that makes it possible.
- scholia 11y ago> If Microsoft ever released the Windows source code, what would we find? Simplicity? Windows source code has been available for a long time under the Shared Source initiative. Some governments (including Russia), large companies, universities, partners and maybe even MVPs have had access to some versions. Email source@microsoft.com https://www.microsoft.com/en-us/sharedsource/ https://www.microsoft.com/en-us/sharedsource/
- kabdib 11y ago> If Microsoft ever released the Windows source code, what would we find? Simplicity? Depends on where you look. Much of the NT kernel is "simple", but it's not easy stuff to get right. There's a bunch of legacy code in the Win32 layers, especially dealing with user input, that is just frightening (comments like "This stupid hack makes the utterly broken Compaq XYZ-3000 keyboard not crash the system"). The COM stuff is just complex and arcane and top-heavy with architecture astronautics. The build system is, or was, a soul-destroying, radioactive and rotting cesspool of Perl; doing Windows builds sucked real hard. So it's a mix of really quite good code, and really quite awful code (that they're dealing with, I think), and code that makes you want to quit, every day. (Soapbox: You should never have code in your project that you are scared of touching. Never. If you do, get rid of it and replace it. Don't layer over it, don't give it to some intern to maintain, just face the problem and deal with it, or it will be the most costly code in your product).
- loginusername 11y agoIf the code were ever released in a form that I could compile myself, and I could omit the parts I did no want... then I might be interested in Windows. Given that MS is a very successful company that got to where it is today based on closed source and copyright, I am not expecting that to happen, ever. I appreciate your candor.
- chadzawistowski 11y agoIf you like small code, simplicity, and a code-audit culture, look no further than OpenBSD.
- loginusername 11y agoA well-deserved endorsement from a Microsoft employee. (Assuming your HN profile is up-to-date.) The kernel I start with is indeed derived from the same one that project started with.
- chadzawistowski 11y agoMy profile is up-to-date, although maybe I should add the caveat that my opinions are merely my own. :)
- loginusername 11y agoOf course. Though I'm sure you are not the only Microsoft employee who has used OpenBSD. At one point, after the Danger acquisition, Microsoft HR was advertising a position for a NetBSD developer. Are there any rules about using a non-Windows OS in the office? Even if it increases your capabilities and productivity?
- chadzawistowski 11y agoNo, there aren't hard rules against it. Practically, however, it's not very useful to use a non-Windows OS depending on which team/product you're working with. For instance, Macbooks are really common on some apps teams. In contrast, I work on the OS itself, so tools such as WinDBG and Hyper-V are essential to getting work done.