Hacker News Reader

Comment by skrebbel | Hacker News Reader

The real news here is that this is considered special.

In most other languages, they'd have forked the source, fixed it, recompiled it for their own uses and submitted a pull request or patch.

I'm a big .NET fan, but the fact that we have to jump through such hoops to find and fix a bug, and then still have near certainty that we're going to have to reapply the patch for many updates to come, well, that's just a bit sad. It feels rather last-century, to be honest. Microsoft could save a lot of double work if they'd just open source .NET and attach a decent process to it. They can still be the Linus. Just consider my patches.

View on HN

---Author here---

I should disclose that I actually work for Microsoft, and still chose the hard way. Fuck the police!

> and still chose the hard way

Chose? Unless you work on the team that made that DLL, it's likely you'd be jumping through hoops even internally.

i'm glad someone who works at the company like you was able to enlighten us as to microsoft's internal practices

oh wait

If you pay any attention to Microsoft, their business practices, news, reports, blogs, etc... then you would know the parent comment is pretty much spot on.

Apply some common sense, you think they let MS employees just commit to any codebase they like? And this is leaving aside all the annoying steps of locating their repository, figuring out how to build it, testing, finding out the right person to send the patch to, going through code review.

How is that any different than a central maintainer of Linux accepting patches and reviewing them before they go in?

The only difference is that you can see the source and test on your own machine first.

MS employees don't have to commit to any codebase they like, but they should be able to obtain the actual source, so that "with enough eyes, all bugs are shallow".

Actually anyone can obtain the source, it's publicly available.

Not sure why you got down voted. I know Microsoft is open sourcing chunks of .net now. Perhaps that chunk wasn't one of them?

"you think they let MS employees just commit to any codebase they like?"

That's pretty much how it works at Google. The code owners have to review and approve your change (and can reject it), but it's common (even encouraged) to commit a bugfix or new feature to someone else's project.

Actually...I heard Google has developed a lot of infrastructure to allow for this: one repository, you can submit changes that are then automatically routed for review and test and such.

It's one of the things Nadella has talked about, and plans to address over time (the extreme compartmentalism of and fierce "not made here" attitude a lot of departments/groups within Microsoft have developed over the past few decades.

On the other hand, a defense of NIH: http://www.joelonsoftware.com/articles/fog0000000007.html

There are ways to get rid of NIH without losing code quality, testings, responsibility, etc. Nadella in particular is talking about encouraging collaboration between departments.

PS: While the linked article is very relevant here, I'm getting tired of people always linking to Joel's blog -- he's not the definitive software spokesperson; has strong opinions which have been shaped by years at Microsoft - and a lot of his opinions are boxed into those views.

From good source here:

You don't actually jump through hoops. All you get to do is submit the bug, which gets logged in the bucket of thousands of other bugs.

Then the PMs will gather for bug triage for the next release, which have to compete with the next shiny project features. Nobody wants to fix bugs that only one developer has. It's just not worth it. This bug has existed for years, and it is likely you could modify your code to generate different byte code.

So the bug likely won't be fixed for a while.

I love .NET. I am just describing the reality of the process of bug fixing. Also, if you fix it, who knows what else will regress. That also imposes a bias towards not fixing these kinds of bugs.

> Nobody wants to fix bugs that only one developer has. It's just not worth it. … Also, if you fix it, who knows what else will regress. That also imposes a bias towards not fixing these kinds of bugs.

This is an interesting cognitive hazard: it's relatively easy to measure the cost of paying a developer to fix a bug and possible to estimate the cost of getting it wrong but there's no way to measure the cost to everyone who encountered it but never did the work to reduce it to a testcase and file a bug report.

Worse, it's very hard to measure the cost of people who choose to use something else. Repeat that cycle a few times and a fairly high percentage of the people you will hear from are in the “never change anything less than critical” camp.

... Or also never fix anything that we won't be able to sell and make money from (this is, the next shiny thing, whatever it happens to be at the time).

The cognitive hazard is a good observation.

But I think the most important one is the imbalance of interest, which is where open source shines: MS gets zero value from fixing this bug and a lot of value from adding new features, but for this one developer this bug could have been the most important issue on the road to his company's "value" (their own product's ship date).

I wonder whether we'll see more of a hybrid model where companies either use something like Red Hat's RHEL / Fedora level of support split or a time-delayed OSS release so they can have some period of proprietary advantage while allowing customers access and allowing some chance for major outside contributions or tangents. Arguably Apple is doing something not entirely unlike that but they haven't hit the right balance yet.

Aren't you allowed to send a git (err tfs) pull request there at least within the company?

I've read several places that even Microsoft is not standardized on a source control management, some use tfs, some svn, some git, etc.

Different VCS is suited to different things. Perforce is great for gargantuan codebases with strong oversight requirements. Git is a poor choice if you check in lots of binaries. SVN is pretty widespread and supported natively by a lot of tools.

Don't think of MS as a single monolith. They're a hundred businesses of various sizes that just happen to share the same HR department.

> use tfs, some svn, some git, etc you can go onto MS's job board and find Rails, iOS, and Node positions. :-D

I know of some teams even still using visual source safe for legacy reasons.

For sure, those who complain about Microsoft not being open source are obviously trying to cover the fact that they are bad at reading assembly language.

Obviously?

Obviously.

That, and they're too poor to buy IDA Pro.

That's the key word that should let you know an attempt at humor was imminent.

Out of curiosity, would you have been able to read the actual source if you wanted?

Microsoft already publishes the source code for the .net framework (and I think other projects like asp.net and mvc) at referencesource.microsoft.com

They do, but interestingly that particular assembly is not included. Or at least I couldn't find it there.

The namespace appears to have changed or something, I found it here:

http://referencesource.microsoft.com/#System.Core/Microsoft/...

Note: also MSFT employee, don't work on .NET though.

---Author here---

I work at MS, and we're using a slightly exotic version of this DLL. Please pardon the differences. :)

---Author here---

Yeah, I've never tried, but I have a copy of the actual Windows source tree, so I'm guessing the answer is yes.

And an extension called Ref12 will also allow you to browse to the online code from Visual Studio.

You chose the really hard way, the reference source is public - http://referencesource.microsoft.com :P

---Author here---

It wasn't that hard. It took us about 30 minutes (thanks largely to the fact that Bart is a genius.) Besides, that's not actually the source of this DLL. We are on .NET native, and for that matter, a bleeding-edge build that's only available here at MS.

Off topic, but I really enjoyed your post about writing a Python lexer/parser in Haskell. Thanks for that!

http://blog.nullspace.io/obvious-python-parser.html

Thanks! I really appreciate it! :D

1) You can file bug reports against .NET and they get fixed. (Typically very slowly, but that's enterprise vendors for you...)

2) The tools they used to find & fix the bug are all based on fully-specified, documented, and supported mechanisms: ildasm and ilasm are stock .NET tools, and ilspy is using Mono's IL decompiler/compiler library.

3) You can compile an app against your own builds of any of the standard libraries if you want (including mscorlib, with caveats) and run it, so a fix like this can be deployed and maintained as much as you like, even if it's not Great Engineering.

4) This hand-patched DLL wouldn't corrupt any other app on your system, and you can ship and version it yourself, so it wouldn't break as a result of a system-wide .NET hotfix or anything like that. .NET's fully-specified ABI also means that it will work across all supported platforms.

5) Mono is open source, so you could always ship against mono and mono's mscorlib (both open source, naturally) if you absolutely can't wait for a .NET bugfix to ship AND you're unwilling to patch the dll yourself.

People love to bitch about .NET, but it actually provides a really good ecosystem here. Very little of it is truly a black box, the spec is extremely readable and precise about the things it covers, IL disassembly is extremely readable, IL disassembly fed through a decompiler like ILspy/dotPeek is doubly readable, debugging is straightforward even without symbols, and recompilation/patching is trivial because everything is well-specified and there's a robust open source library for it. (Even if there wasn't a library, you could just use the standard ildasm/ilasm pair.)

Oh, and you can compile native no-kidding C/C++ to .NET targeting the same instruction set and get all the benefits of the above. If you want to.

>(Typically very slowly, but that's enterprise vendors for you...)

Ah yes, that's why you pay $$$ for software :).

Re "you can ship and version it yourself"... yeah, now that's where this gets onto shaky ground, isn't it... redistributing recompiled versions of .NET code? That's not really inside the licensing rules, is it.

I completely agree with everything you said. Exactly how are we disagreeing?

My point is that MS should open source .NET. With a good governance process (super dictatorial no problem! Just be open so we can chip in). It's good for them and for us .NET devs. There's nothing to lose. Like you write, there's a lot of things great about .NET. But being closed source is a disadvantage.

I've very rarely heard of shops running forked, re-compiled runtimes for languages like python or ruby.

Normally if you find a bug in the core you might try to monkeypatch but many times that won't work so you have to suck it up and just work around it.

There's actually a bunch of shops running forked and recompiled runtimes for languages like python and ruby. I happen to work for a company who maintained such a fork (Ruby Enterprise Edition, by Phusion), and we weren't the only ones who had forks. Most famous were the MBARI patches, made by a guy who worked at MBARI and needed those for running ruby in a submarine or something :P The patches were actually very impressive, despite coming from a biology research institute.

(Note that these were forks because they changed aspects of Ruby that were not in line with Ruby's general purposeness, so they were not allowed to merge into mainline Ruby)

OK, but my point still stands since the vast majority of companies are not maintaining their own forks. In the rare situation where they need something special they'll rely on someone upstream, like your company, to fork it for them. Most companies that run into a bug in the core runtime will just workaround it.

I work at a startup that uses almost all open source tools for our stack. To not be able to fork, fix, pull request a bug in software seems...barbaric to me.

What they're doing here is monkeypatching the language runtime. That's not trivial in most languages, least of all ones which typically rely on a centralized install of that language runtime to function.

The way they did this, only the program that needs this fix is actually using their monkeypatched Expressions library; other code on the same system - other libraries in the same application, even - will continue to use the standard .NET runtime classes. That's a pretty powerful capability, and not one that is necessarily made easier by an open language runtime.

no they aren't.

monkey patching refers to dynamic modifications of code/behaviour at runtime.

this is simply editing a file on the disk, which people cracking software have been doing for about 30 years (using exactly the same method).

Regarding open-sourcing .NET: did Microsoft not precisely do this (at least some of its components)? http://thenextweb.com/microsoft/2014/04/03/microsoft-cloud/

It's not that special, and they took one hell of a circuitous route to fix their bug. You can download the source and view the bug here:

http://referencesource.microsoft.com/#System.Core/Microsoft/...

---Author here---

We actually chose the most expedient route. The reason is, the source you link to is not actually the source of the DLL we were working with. That particular file is very similar, but the rest of the repot is very much different from the version we were working on. (I work at MS, and our project is kind of exotic in this case.)

I know what you mean, I like .NET too but there is a lot about working with it that feels very outdated these days.

Reply on news.ycombinator.com