![]() ![]() ![]() Oh god, the NTFS code is a purple opium-fueled Victorian horror novel that uses global recursive locks and SEH for flow control. We can't touch SDX, so let's pretend for four releases that we're moving to TFS while not actually changing anything! We can't touch Source Depot, so let's hack together SDX! Let's support symbolic links, but make sure that nobody can use them so we don't get blamed for security vulnerabilities (Great! Now we get to look sage and responsible!) ![]() Why would anyone need an archive format that supports files larger than 2GB? So we create another %C#_REMOTING_FLAVOR_OF_THE_WEEK%! We can't expose %INTERNAL_NOTIFICATION_SYSTEM% to the rest of the world because we don't want to fill out paperwork and we're not losing sales because we only have 1990s-era Win32 APIs available publicly. Let's add %INTERNAL_NOTIFICATION_SYSTEM%! And let's make it inconsistent with virtually every other named NT primitive. Many of us wanted to improve cmd.exe, but couldn't.) (That's literally the explanation for PowerShell. New features help much more at review time than improvements to old ones. Look at recent Microsoft releases: we don't fix old features, but accrete new ones. These junior developers also have a tendency to make improvements to the system by implementing brand-new features instead of improving old ones. These developers mean well and are usually adequately intelligent, but they don't understand why certain decisions were made, don't have a thorough understanding of the intricate details of how their systems work, and most importantly, don't want to change anything that already works. You find SDEs and SDE IIs maintaining hugely import systems. Google and other large Seattle-area companies keep poaching our best, most experienced developers, and we hire youths straight from college to replace them. Is it any wonder that people stop trying to do unplanned work after a little while?Īnother reason for the quality gap is that that we've been having trouble keeping talented people. If you're unlucky and you tell your lead about how you improved performance of some other component on the system, he'll just ask you whether you can accelerate your bug glide. Incremental improvements just annoy people and are, at best, neutral for your career. Yes, making a massive improvement will get you noticed by senior people and could be a boon for your career, but the improvement has to be very large to attract that kind of attention. Here, if you do that and you're not on the object manager team, then even if you do get your code past the Ob owners and into the tree, your own management doesn't care. ![]() On linux-kernel, if you improve the performance of directory traversal by a consistent 5%, you're praised and thanked. There's also little incentive to create changes in the first place. You can always find a reason to say "no", and you have very little incentive to say "yes". There's just no incentive to accept changes from outside your own team. See, component owners are generally openly hostile to outside patches: if you're a dev, accepting an outside patch makes your lead angry (due to the need to maintain this patch and to justify in in shiproom the unplanned design change), makes test angry (because test is on the hook for making sure the change doesn't break anything, and you just made work for them), and PM is angry (due to the schedule implications of code churn). Our low performance is not an existential threat to the business. We started caring about security because pre-SP3 Windows XP was an existential threat to the business. There's no formal or informal program of systemic performance improvement. We can and do improve performance for specific scenarios that people with the ability to allocate resources believe impact business goals, but this work is Sisyphean. Granted, occasionally one sees naive people try to make things better. There's almost none of the improvement for its own sake, for the sake of glory, that you see in the Linux world. Windows is indeed slower than other operating systems in many scenarios, and the gap is worsening. ) I'm posting through Tor for obvious reasons. (Proof: the SHA1 hash of revision #102 of is. I'm a developer in Windows and contribute to the NT kernel. His post has been deleted! Why the censorship? I am reposting it here. And out of nowhere an anonymous Microsoft developer who contributes to the Windows NT kernel wrote a fantastic and honest response acknowledging this problem and explaining its cause. I was explaining on Hacker News why Windows fell behind Linux in terms of operating system kernel performance and innovation. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |