9 ms·

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.

by nknight 15y ago

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.

angersock 15y ago
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. 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. 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>
- nknight 15y ago
  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.
  - angersock 15y ago
    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.
    - tptacek 15y ago
      "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.
- tptacek 15y ago
  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.
  - angersock 15y ago
    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.
tghw 15y ago
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.
- nknight 15y ago
  > (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.
  - tghw 15y ago
    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.
saurik 15y ago
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.
- eps 15y ago
  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.
  - johnm 15y ago
    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.
    - eps 15y ago
      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.
  - saurik 15y ago
    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.
  - 15y ago

by nknight 15y ago

angersock 15y ago

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. 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. 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>

nknight 15y ago
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.
- angersock 15y ago
  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.
  - tptacek 15y ago
    "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.
tptacek 15y ago
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.
- angersock 15y ago
  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.

tghw 15y ago

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.

nknight 15y ago
> (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.
- tghw 15y ago
  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.

saurik 15y ago

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.

eps 15y ago
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.
- johnm 15y ago
  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.
  - eps 15y ago
    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.
- saurik 15y ago
  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.
- 15y ago