Hacker News Reader

Comment by nknight | Hacker News Reader

The fundamental problem people are having seems to be "antirez won't support Windows".

Let's say BigCorp really wants to use Redis, but only supports Windows.

Why is it OK for them to ask antirez to support Windows, but not OK for antirez to ask them to support Linux/POSIX?

Don't go with a kneejerk response, think about it.

Neither party in this relationship has any special obligation to the other, there's no contract, no money is changing hands.

BigCorp wants antirez to support their preferred software (Windows), antirez wants BigCorp to support his (Linux and/or POSIX).

It will cost BigCorp more to support POSIX, you might say. But cost them more relative to what? Of their tens of thousands of employees, billions in revenue, BigCorp would be dedicating an infinitesimal fraction of its resources to supporting a POSIX-compatible OS.

Meanwhile, a huge fraction of antirez's time will be spent dealing with the effects of trying to maintain a high-performance, low-level datastore on two utterly incompatible platforms, and the time he spends on that is time taken away from work on other bugs and features, which also amounts to time taken away from all the people who already use Redis on POSIX.

There is no incentive at all for antirez, his employer VMware, or the Redis community at large to go through the pain of integrating Windows support into Redis mainline. There is some incentive for BigCorp to support Linux, since they want to use Redis effectively.

The incentivization is exactly backwards, so it should surprise absolutely no one that antirez isn't prepared to deal with supporting Windows.

View on HN

FWIW, Microsoft does ship a POSIX implementation called "Subsystem for Unix-based Applications", and it in fact has a working (and I think efficient?) version of fork() (which sounds to be the only thing redis would actually be wanting for once ported to libuv, as this patch does; although, for all I know, libuv doesn't support SUA); that said, it is now deprecated, and will be removed after Windows 8.

There is no equivalent to epoll on Windows. There is select (that just happens to get slower when socket's numerical id gets larger). There is also IOCP, which is an ass-backward epoll - a typical Microsoftish contraption that was supposed to be better by being more universal, but ended up being a retarded piece of disaster compared to epoll. I killed a couple of months trying to push and shape IOCP back into the BSD style API, and in the end it worked, but the guts were ugly and the process was utterly unpleasant.

So, no, the "subsystem for unix-based applications" is a no go.

That's because you picked the wrong direction to manage things... check out libuv and how they've built their api in the other direction.

It's not a wrong direction necessarily, it is just a different abstraction level. I did what I did, because of the constraints of the existing codebase. If one abstracts above the socket level, things are getting less hairy, but it also translates into substantially more per-platform code. It also makes the abstraction less flexible.

I did say "which sounds to be the only thing redis would actually be wanting for once ported to libuv, as this patch does", a critical aside that you seem to have ignored.

If node.js could make things work on Windows using IOCP then redis could do the same. For starters, they could study the node.js code to compare the epoll version with the IOCP version in order to understand how to use IOCP,

Think about it from the cost perspective. Not necessarily in terms of dollars, but in terms of time. There are thousands of BigCorps out there. There is only one Redis. If every BigCorp that runs mainly on a Windows stack (I'm personally connected to two, Fog Creek and StackOverflow) has to spin up %nix boxes just to run Redis, there will be tens of thousands of hours wasted as each company gets this new environment up and secures and maintains it going forward.

However, if he does support Windows, it might take antirez some extra time to support this patch, mostly front loaded. If it is too much for him personally, he could ask just one of the BigCorps who care about it for some help. (I'll bet Microsoft would be willing to dedicate a dev or two.) The number of hours spent may be in the tens to hundreds, but will be much more efficient overall.

> (I'm personally connected to two, Fog Creek and StackOverflow)

The latter of which, at least, has done exactly what you say you don't want to have happen. Also, neither of those companies are even remotely BigCorp, they're quite small and nimble.

> has to spin up %nix boxes just to run Redis, there will be tens of thousands of hours wasted as each company gets this new environment up and secures and maintains it going forward.

Perhaps an incentive for them to find a way to make an unobtrusive patch that might be accepted into Redis mainline. Or an incentive to press Microsoft for real POSIX support.

None of this is an incentive for antirez, VMware, or anyone else, other than the people who want to run Redis in Windows.

At best, you're arguing the good of society, but getting agreement on what that means requires someone to have made a lot of moral and ethical judgements similar to yours.

You are right in that we're not BigCorps, but if anything, that makes it worse, as we don't have as many resources to spend setting up boxes we wouldn't have otherwise needed.

It's not a moral and ethical calculation, it is a simple calculation of time. One of our main goals in the software industry is to reduce redundancy. Antirez's decision is increasing it.

Arguing simply based on incentives is also a fallacy. If we were to look at everything from that perspective, no one would donate to charity and far fewer open source projects would exist.

Antirez's decision is decreasing complexity and time for him and the people who help maintain his project.

The code is right there. Any of your BigCorps are free to grab it and make it work. They are not free to demand the time of an open-source dev.

Forking the project is less than ideal. Client libraries will have to spend time making sure they comply with both versions, and development in general will slow as each project will have fewer total devs. Better to bring that other team "in house" and have them help with any issues that come up due to the new cross-platform code.

  > Forking the project is less than ideal.

Except when the author of the project says he won't roll Win32 support into mainline development. Then it's the only option, but it's an option available solely because the author open-sourced his code under a license that allows it. Which is awesome.

  > Client libraries will have to spend time making sure they 
  > comply with both versions

I'm not sure that's the case. If I'm writing a Redis library (say Resque), I'm going to ensure it works with Redis. If it's also usable on Windows because of redis-win32, awesome, but that's not something I'd go out of my way to ensure.

  > development in general will slow as each project will have fewer total 
  > devs.

What? Why? Why would a project have fewer devs? Are you assuming some developers will work only on redis-win32 and not on mainline Redis? I don't think that follows -- changes to mainline Redis will probably be merged downstream into the win32 fork by that fork's maintainers, who wouldn't otherwise be working on Redis.

Standardizing on Windows as a deployment platform has known costs and benefits. One of the costs is in largely losing out on the traditional UNIX software ecosystem.

There are some OSS projects that maintain first-class Windows support, but nobody should be surprised that when they find out that Windows is poorly supported by an OSS ecosystem that is predominately focused on producing software for UNIX descendent systems.

Nobody is saying that they should standardize on Windows, just support it. The way Microsoft did the patch, using a cross-platform library that has support from another popular project, is the perfect way to address this issue.

I was referring to the IT choice to standardize on Windows as a deployment platform for your organization.

As for Reddis, the cost of supporting another operating system -- especially one as different as Windows -- is quite high. If you don't use Windows, there's little cost justification for doing so.

In terms of economic efficiency then:

This being a BSD product, BigCorp can do their own port. They can decide to release it or not, based on whether it is more economical for them to share the support load (but also provide the "profit" to their competitors), or not.

Microsoft chose not to with their BSD Socket modification, for example. They can just as well do the same for Redis.

Pure and simple, this is Microsoft tried to get something (remove incentive for people to use competitor) for almost nothing.

When Microsoft NoSQL server arrives (and I suspect it would, sooner or later), if it is even remotely competitive with Redis, you can be sure they'll speak badly of Redis -- they do that to their own products when a new version is out.

So, let's talk about the incentivization issue first.

Why is it OK for them to ask antirez to support Windows, but not OK for antirez to ask them to support Linux/POSIX?

Because antirez has a tool whereas BigCorp presumably has a problem. Because all of us could benefit from this, while only some of us might benefit from BigCorp switching to Linux.

Asking somebody to make their tool more available is, I posit, much more reasonable than asking somebody to change their problems.

BigCorp has potentially hundreds of thousands tied up in existing equipment, IT infrastructure, and training for employees. You and I might not flinch at spinning up a VM to run a database, but we (and the rest of the HN community!) should not fool ourselves into thinking that this is in any way always appropriate for a company.

Or, you know, he might talk with the Microsoft development team and try to get them to take over maintenance of the Microsoft codebase, and clean up the platform-specific architecture that gets in the way--and in so doing, write better code.

If you can't/won't write platform-independent code, you are either lazy or your problem domain is heavily dependent on your platform. As far as I know, in-memory key/value stores aren't a Linux-specific problem, so...

<rant> There is no incentive at all for antirez, his employer VMware, or the Redis community at large to go through the pain of integrating Windows support into Redis mainline.

Let's look past incentives here. Let's talk about Doing the Right Thing.

A huge number of people here make daily use of software packages and stacks that are open source. We owe our livelihoods to the folks that have been kind enough to release the source to their programs and, more importantly, work with the community to improve their code.

We owe it to ourselves and our community to call out people being lazy and selfish, and letting politics overrule sound engineering and decency.

This is an unreasonable decision by antirez. He's got a cool framework. He's got a bunch of code and (presumably) people that are happy to work with him on making it even more useful.

He's also not going for it, because "use linux lol". Not because it's hard, not because he doesn't have folks that can add it, not because the problem extends beyond some refactoring and #ifdefs and makefiles.

Because he's lazy. Because Linux is the One True Way. Because helping out anyone who can't just change their infrastructure on a whim is too much to ask.

Really folks? You don't see a problem with this? </rant>

What a disgusting assault on Salvatore's character. I really don't think anything more needs to be said, your resorting to such attacks pretty well speaks for itself.

Sir or madam, if you would like to articulate why you classify my observations (and in the rant section, opinions) as disgusting, I would very much appreciate the insight.

If I have misclassified the situation, by all means, enlighten me.

"use linux lol" is probably the point where you really set him off, but your entire argument is juvenile.

There is a dollar amount that would get Salvatore to do a first-class WinAPI Redis implementation (he won't advertise it, and may not even believe it exists, but I assure you that there is one). Pitch numbers to him until you find it, then, pay him. You may or may not choose to share your newly purchases WinAPI Redis with the rest of the world --- bear in mind that there are enterprise products with mid-5-figure per unit price tags that do nothing but provide WinAPI-friendly .NET-compatible memcached.

Guy writes code for Linux. Code could theoretically be made to work on Windows. Windows users are therefore entitled to a Windows port.

That's roughly your argument here; I've just done you the favor of adding concision to it. The motivations of all the parties involved, enterprise IT costs, all that jazz, none of that matters. Fundamentally you're saying "if something can be made cross-platform, it's wrong not to make it cross- platform".

That is, to say the least, a comical argument coming from people who want Linux code deployed on Windows.

Guy writes code for Linux. Code could theoretically be made to work on Windows. Windows users are therefore entitled to a Windows port.

Not quite.

Guy writes code for Linux. Code could theoretically be made to work on Windows. Microsoft team submits patch to achieve this functionality. Users can reasonably expect a Windows port. Guy decides using submitted code is too much effort (from article says will get harder and harder) and that besides, there is no demand for it (from article: "I don't think Redis running under win32 is a very important feature."). Users have been denied functioning code because of arbitrary decision by guy.

You wrote (and I numbered):

(1) Guy writes code for Linux. (2) Code could theoretically be made to work on Windows. (3) Microsoft team submits patch to achieve this functionality. (4) Users can reasonably expect a Windows port. (5) Guy decides using submitted code is too much effort (from article says will get harder and harder) and that besides, there is no demand for it (from article: "I don't think Redis running under win32 is a very important feature."). (6) Users have been denied functioning code because of arbitrary decision by guy.

(4) simply does not follow from (1), (2), and (3), derailing the whole rest of your argument.

Salvatore doesn't owe anyone a damn thing. He has the opposite of set the expectation that there will ever be a Windows port, so any user who thinks they can "reasonably expect one" is delusional.

Anyone who says otherwise is arguing for the sake of arguing. Writing a program specifically for Unix is obviously a totally reasonable thing to do, just as it makes zero sense to demand Panic provide a Windows port for Transmit, or that Microsoft provide IIS7 for FreeBSD.

If I'm not mistaken, 4 actually very much does follow from the preceding points.

The code is brought into existence. Code is observed to be capable of being modified into working on Windows (i.e., nothing radically platform-centric about it). Microsoft provides the grunt work to accomplish a patch that proves this observation true.

Very much, by definition, users can reasonably expect a Windows port. The capability exists. The code exists. The patch functions. If Windows User Clippy says "I expect that redis will be ported to Windows, given these facts", Clippy is not being unreasonable.

I'm sorry, but to claim otherwise is merely being obtuse.

Your points about IIS7 and Transmit are correct, as those rely on specific OS functionality that is unique--the constructs Redis uses are not, and again code has been written to show this fact.

Now, there very much is something to be said for Salvatore (antirez?) not having to do this work for free. Indeed, VMWare may be spending a good chunk of change paying for his services ( http://antirez.com/post/vmware-the-new-redis-home.html ). I do not wish to suggest that he go uncompensated.

What I do wish to suggest is this:

VMWare: this dude you are paying to develop a widely-used and respected project has (seemingly arbitrarily) turned down code submitted from other practitioners in the field. He has suggested they fork the project (diluting the quality of the Redis brand and potentially removing resources that could improve mainline Redis). He has suggested that the project is too difficult to make cross-platform; I'm sure that you folks might have a different opinion on how important cross-platform support is.

Pay him more to make a better project (with help from people in the community!). Or acknowledge that he is correct in his assessment that this is somehow a Linux-only problem. Or do something else to help him figure out how his goals align with the VMWare mission.

318 words that say almost nothing, because they are premised on the ideas that:

* If someone writes a patch for your project, the burden of proof is on the maintainer not to accept it, rather than on the submitter.

* If someone domiciles their open source project at VMware, they assume an obligation to all of VMware's customers.

Neither statement has any truth to it. You're just throwing stuff at the wall to see what will stick, which is why your comments are turning light grey and mine aren't.

Can I ask you an orthogonal question?

What's the last project you used Redis on? How'd it turn out for you? What do you like about Redis?

Most laughable is the idea that VMware would have any reason to ask him to make Redis run on Windows. They make a lot of money off enabling easy deployment of diverse operating systems.

About that, VMware does a remarkably cool work to be fair with other companies (at the point I had problems understanding this behavior in the first months: in Europe competition is sensed always as something dangerous and I'm glad that VMware attitude is different), and in this specific instance I did not received any pressure about avoiding to support win32, actually I got some suggestion to be more open if the win32 port will become more reasonable/complete.

> If I'm not mistaken, 4 actually very much does follow from the preceding points.

Then you should go back to logic school. Let me make it clearer for others reading this, as yourself appears to be a lost cause:

(1) Microsoft develops web browser (2) rendering could theoretically be made standard compliant with minor changes (3) people submit style sheets and javascript files that, if included in a web page (or embedded into IE) would achieve that functionality. (4) Users can reasonably expect Microsoft to do that.

Wait, what?

Furthermore, your logic breaks in other places:

(5) ... there is no demand for it (from article: "I don't think Redis running under win32 is a very important feature.").

How does "not important" imply "no demand"? Let me give you an example that will make it clear:

"Apple just said that getting Win7 apps running on the iPad is not important". You bet there's demand for that, and yet that does not make Salvatore's or this (fictional, but realistic) Apple quote wrong in any way. "important", unless otherwise qualified, is to the speaker.

(6) Users have been denied functioning code because of arbitrary decision by guy.

Wrong. They could just build it from source. Less convenient? Well, it takes just one person to package it and make it into an .msi.

Furthermore, the decision is not arbitrary -- you may disagree with the reasoning, but he gave detailed reasoning.

You sir, are either an idiot or a masterful troll -- I would pick the first, if only because it makes me feel better to think I haven't been trolled :)

We shouldn't call people idiots, or, really, trolls. Berate the argument, not the commenter.

That's true. And I mostly follow this.

When the other person consistently ignores logic and invents their own facts and reality, I occasionally adopt the Linus strategy; but I still take care to address the argument itself.

Point well taken. HN is a better place thanks to people like yourself.

Blah, I'm 100x worse than you are about calling people names, but for what it's worth: if you write a similarly worded comment to me, I'll try my best to thank you for it instead of getting bent out of shape. :)

Please stop trying to condense my arguments, as you seem to keep doing so and augmenting them with incorrect analogy. Your example with the Microsoft web browser is disingenuous, as it involves a closed, proprietary system, and your suggested patch involves a workaround on the part of users.

This is a direct patch applied to an open codebase, which in turn allows users to reasonably expect that, there being no technical or resource obstacles to implementation, a platform port could be expected.

Your critique of my 5th statement is not unfair--I should've elaborate on the connection between "not important" and "no demand". I was in error. Your analogy using the iPad simply muddies the waters.

Your critique of my 6th statment is also unfair. The decision was arbitrary (we know that technical constraints don't exist, and that it isn't "free work" being asked for unreasonably). Asking people to just build it from source is not good for users, and forcing the creation of a fork of a codebase is not good for developers. You are being unreasonable, I believe.

The reasoning given for the decision is heavily based in arbitrary judgements not backed by valid engineering concerns (a lot of that low-level OS stuff? Yeah, actually pretty standard across operating systems, though the incantations may be different).

You sir, are either an idiot or a masterful troll -- I would pick the first, if only because it makes me feel better to think I haven't been trolled :)

I wasn't attempting to troll here, and I prefer not to think of myself as an idiot--then again, I also prefer to debate with people who can structure arguments without excessive namecalling or misleading strawmen.

> your suggested patch involves a workaround on the part of users.

EXPLICITLY BECAUSE microsoft refused to patch internally, which is what you think antirez is doing wrongly!

> Your example with the Microsoft web browser is disingenuous, as it involves a closed, proprietary system, and

So? Where is the contract, written or social, that antirez signed, which predisposes him to accept patches that go against his philosophy of keeping the code base lean, simple and efficient?

> This is a direct patch applied to an open codebase, which in turn allows users to reasonably expect that, there being no technical or resource obstacles to implementation, a platform port could be expected.

THERE ARE TECHNICAL OBSTACLES, CLEARLY DETAILED BY ANTIREZ. You might disagree with them, but they are not empty words. And furthermore: WHY? WHY SHOULD IT BE EXPECTED?

> The decision was arbitrary (we know that technical constraints don't exist,

PLEASE READ ANTIREZ AGAIN (AND AGAIN (AND AGAIN)) THERE ARE LEGITIMATE CONCERNS WHICH YOU FAIL TO ACKNOWLEDGE

> The reasoning given for the decision is heavily based in arbitrary judgements not backed by valid engineering concerns (a lot of that low-level OS stuff? Yeah, actually pretty standard across operating systems, though the incantations may be different).

So please explain to everyone how easy it is to do copy-on-write from memory to disk without pausing and without fork() -- because THE GUYS AT MICROSOFT WHO SUBMITTED THE PATCH DON'T KNOW HOW TO DO IT. THEY THINK THEY MIGHT HAVE A SOLUTION BUT HAVEN'T POSTED ONE YET.

> You are being unreasonable, I believe.

The only unreasonable thing I am still doing is replying to you. We apparently live on different planets. ANTIREZ HAS NO COMMITMENT TO THE GOOD OF USERS OR DEVELOPERS. Furhtermore, ANTIREZ BELIEVES AT THIS POINT SUPPORTING WINDOWS WITHOUT FORKING IS AGAINST THE GOOD OF USERS, DEVELOPERS AND HIMSELF, as he has clearly stated.

> I also prefer to debate with people who can structure arguments

Funny ! I'll come back to this post when I need another laugh!

> If you can't/won't write platform-independent code, you are either lazy or your problem domain is heavily dependent on your platform. As far as I know, in-memory key/value stores aren't a Linux-specific problem, so...

If you can't write your OWN in-memory key/value store, you are either lazy or a parasite.

> Let's talk about Doing the Right Thing.

The right thing for people like you is to, you know, just maintain and release their own Redis port. It is BSD licensed - you don't even have to release the source code if you don't want to. And in fact, a port already exists. So you are either lazy, a parasite, or a troll.

> Because helping out anyone who can't just change their infrastructure on a whim is too much to ask.

Money talks, bullshit walk.

> Really folks? You don't see a problem with this?

Yes, I do see a problem with people like you who feel entitled.

I haven't seen any complaints about Microsoft dropping POSIX support (which, if it was actually usable, would have supported redis out of the box).

If you can't write your OWN in-memory key/value store, you are either lazy or a parasite.

If you can't write your own green threading library, you are either lazy or a parasite. Please let's be reasonable about what is worth rewriting and what is not.

This attitude is why so many man-hours are lost in the community, and why so many pointless forks exist. Come now, do you honestly believe this is a more efficient/sound/useful solution than trying to get antirez to just add support in mainline Redis (without even having to start from scratch)?

Money talks, bullshit walk.

Care to elaborate? I'm not fluent in "tired cliche".

I haven't seen any complaints about Microsoft dropping POSIX support (which, if it was actually usable, would have supported redis out of the box).

I imagine that there were, in certain circles, a lot of annoyance at this. My team and I do a lot of cross-platform C code, and this would've made our lives a lot easier. Then again, if people complained (as I did here!) perhaps things may have gone better?

> If you can't write your own green threading library, you are either lazy or a parasite. Please let's be reasonable about what is worth rewriting and what is not.

I was mocking your statement, in case you missed it. I don't think that if you don't write cross platform code you are lazy -- especially not high performance code that derives some of its performance from platform specific features!

And no one needs to rewrite anything! Just use your own fork with your PATCHES. Read my lips again: NO REWRITE NEEDED!

> This attitude is why so many man-hours are lost in the community, and why so many pointless forks exist.

For some reason, you believe the community owes you something. And what exactly are those "so many pointless forks that exist"? GCC has had 5 significant forks through its life, non of them pointless.

> Come now, do you honestly believe this is a more efficient/sound/useful solution than trying to get antirez to just add support in mainline Redis (without even having to start from scratch)?

Of course it is efficient for parasites like you when antirez spends the time -- especially since you don't care about development efficiency and speed on Linux which are essentially guaranteed to be harmed, at least in the short term and possibly for a long time to come.

The only question is: why should antirez care?

> Care to elaborate? I'm not fluent in "tired cliche".

SPEND TIME (which translates to SPEND YOUR INCOME which translates to SPEND MONEY) MAINTAINING A WINDOWS FORK, TO ANTIREZ STANDARD OF PERFORMANCE ON LINUX AND CLEANLINESS OF IMPLEMENTATION, and if you manage to achieve that, I can almost guarantee he'll merge it in. The problem is, it might not actually be doable -- but TALKING ABOUT IT IS CHEAP FOR YOU, so that's what you do -- which is what others tend to call BULLSHIT. Is this elaboration enough?

> My team and I do a lot of cross-platform C code, and this would've made our lives a lot easier.

Translation: We would have gotten something for nothing.

Question: Does your team release any of its code? If so, can I have a look? If not, why not -- and why do you feel entitled to someone else's source code?

> Then again, if people complained (as I did here!) perhaps things may have gone better?

Oh, you are so naive. The only reason the posix subsystem existed in the first place was so that NT would be eligible to compete in Government tenders (predominantly, but not only, US). It was always a 3rd class citizen, hardly supported or usable, although it was very successful in the business sense of letting MS compete in those tenders.

Microsoft only fixed browser standard compliance (and not fully) when they realized they're starting to lose the browser war again. That's 10 years of very vocal complaints that went unheard, and for a very simple reason: It conflicts with their lock-in strategy. Same thing about the posix extensions.

You might be a very good developer for all I know, but you really fail in understanding how the world works.

Translation: We would have gotten something for nothing.

Actually, we would've been able to focus on mainline development instead of having to write some supporting libs. That said, having written that code, we now are going to share it with the rest of the world, so they don't have to waste time doing what we did. If you'd like to leave an email address here, I'll cheerfully send you notice of our release personally.

Question: Does your team release any of its code? If so, can I have a look? If not, why not -- and why do you feel entitled to someone else's source code?

We're releasing a cross-platform low-level OS, threading, and math library for C under either the WTFPL or BSD license around New Years. This library will have a public bug tracker, open source, and excellent documentation for usage and code commenting as well overall package design so that others may extend it easily if they wish.

Sir or madam, call me whatever you wish, but at least be accurate. I am no parasite.

Cool. Just post to HN. I'll upvote it and post a thank you note for the release.

My email shall remain hidden for now.

> We're releasing a cross-platform low-level OS, threading, and math library for C under either the WTFPL or BSD license around New Years.

Great. I will keenly be following your responses to contributed code to see how you believe it should be done.

  > He's also not going for it, because "use linux lol". Not 
  > because it's hard, not because he doesn't have folks that 
  > can add it, not because the problem extends beyond some 
  > refactoring and #ifdefs and makefiles.

  > Because he's lazy. Because Linux is the One True Way. 
  > Because helping out anyone who can't just change their 
  > infrastructure on a whim is too much to ask.

Seriously? Because he's lazy? Antirez, the author of Redis, is lazy because he won't port his software to the only major non-UNIX platform?

What a load of entitled bullshit.

If I choose to run my infrastructure on Linux I can't complain that I don't get Microsoft's Active Directory. That's one of the consequences of the decision I made. When you choose Windows as your platform, these are the consequences.

You don't get to later yell at the developer of an open-source project you like and call him names because he won't take the time and effort to make his project run under an OS that's significantly different from the one he writes for. Especially after he's said that even though he won't support Windows, he will bless a Redis-win32 project run by someone else.

Yes, let's talk about "Doing the Right Thing." Take the patch Microsoft's team provided and start maintaining it. Write tests and documentation, fix bugs, make it work. Antirez says he won't support Windows himself? There's the code, make it happen. That's why open-source software is awesome.

  > We owe it to ourselves and our community to call out people being lazy and 
  > selfish, and letting politics overrule sound engineering and decency.

You're right. You're being lazy and selfish when you demand that other people make their open-source software for Platform X work on completely different Platform Y just because some folks base their infrastructure on Platform Y. Sound engineering has nothing to do with it, Redis is sound. Decency never comes into play because what operating system your software runs on has nothing to do with morality.

Reply on news.ycombinator.com