But you said, there are other instances of win32 ports of system software like MySQL, MongoDB and so forth. I guess that they are interested in providing more value to their product allowing a larger diffusion, I'm not enough into marketing to value such a thing, in my opinion people running Apache or MongoDB under win32 for deployment are doing it wrong, and I don't want to help.

But again, I just don't want to personally help an effort that is useless in my opinion, but I'm not either against such an effort. Redis is open source, enough people interested in making it working under win32? Perfect, as I said I'm open to help and recognize their efforts in the main project site, I just don't want to be involved. Life is too short to spend it developing something you don't trust.

In the first versions of Kiln, we had to ship a Python clone of Redis we called MiniRedis (it only implemented the subset of commands we used) because of the lack of Windows support. We're now shipping the Cygwin build of Redis to run on Windows, which is less than ideal.

I sincerely hope you'll reconsider your position. I believe it is, at best, myopic to think that %nix is the only place people will want to host Redis, or that it has in any way "won" as the only hosting platform.

When you decided to write an application in .NET, meant to be run on Windows, why did you also decide to use an in-memory datastore that doesn't run on Windows? That seems like a really bad design decision for that product.

That's how it should be - you've made a choice of development platform, you get to live with the trade-offs, one of them, for the time being, being "no good native redis".

It does of course make sense as I assume you're developing this because you want to, and not as part of a company's bottom line, which means really you can do whatever you like. No sense developing something if you're not enjoying the process. If however you ever take this to a level where you have a financial incentive in furthering the software's adoption, I'd urge you to do whatever it takes to get an official Windows port in there, which would mean looking at any aspects of the implementation that cause issues on that platform, and doing what you can do to overcome them.

However, even if this was a commercial project, this would still be the correct decision. Innovating new features, polishing and making Redis even better is exactly what @antirez should be doing.

Make an awesome product. Not a half-assed one that runs on every device / os / mobile under the sun. I've seen more than one project dissolve in mediocrity under the pressure of trying to do that.

Curiously, I noticed unix sockets had been officially added in version 2.2.0.

I agree that installing Redis on Windows is kind of "doing it wrong", but the ability to easily access a Redis server with redis-cli even on Windows seems to be pretty important to the continued increase in user base.

Thoughts?

EDIT: I understand there is a redis-cli for Window at https://github.com/dmajkic/redis/downloads , but a separate download that users must know about and keep up to date separately is a barrier to entry, IMHO.

For convenience you could also run any Linux-specific software in VirtualBox or VMWare on the same machine. You could also install an X-Server on Windows and open Linux apps in their own window on the Windows desktop. I've done it, works great. And you can always find somebody to help out, you only need to ask. Haven't you heard? Virtualization is the future ;)

It is an author's right to devote his time to whatever the fuck he feels like doing. If he feels like there are more important things to work on, rather than Win32 support, then so be it.

If you can't stand this situation you can always port it yourself, send a patch, etc, etc... You can also be hard-core, like the Mono people that reimplemented .NET from scratch because Microsoft doesn't think of Linux as a useful target.

Isn't the whole point of this article that Microsoft sent a patch, and it is being rejected, just to avoid supporting win32?

That's why they are rejecting the patch. Because it doesn't provide anything new while adding complexity. Not because they want to avoid supporting Win32.

So you are seeing that anyone who wants to see win32 support should stop moaning send a patch.

But then, any such patch would add extra code and an abstraction layer, so therefore must be rejected.

So, sending a patch isn't actually useful at all then.

The patch will not make Redis behave well on Win32, Redis will still remain unusable for production environments and Redis already works well enough on Windows for development purposes.

Really, dismissing this patch is a no-brainer - and even though the author said that he prefers to keep it POSIX-only anyway, I'm sure they'll reconsider if they receive a proper patch that fixes the problem, but for the moment there is no such patch.

If there would be a patch that fixed the problem, this whole discussion would be a non-issue, even if the patch wouldn't get integrated in the main branch - somebody (if there indeed is interest) will create another branch specific for Win32 and everybody will be happy. But we can't even have a discussion of branching or not, because there is no such patch available.

So I don't see what's with all this arguing.

BINGO.

Hence, he isn't.

But when he follows your own logic, you call him "narrow minded".

On the contrary, porting front end software between platforms makes a lot of sense, but that's a completely different story.

If I have a desktop app which talks to Redis (for whatever reason), what this means is that I can't realistically produce a version which works offline. Depending on the market, that could be huge.

Instead of running "redis.exe" (which you installed), you run "virtualbox redis.vdx". You could even have the inner redis use the outer disk with a little more work, running the internal vm read only. Configuration is slightly more complicated, as you have to both configure the inside redis and the outside virtualbox -- but it's all just a few short text files, and you only need to do that once.

You can produce a version that works offline. You can even bundle it inside your product (virtualbox and redis both being free). And you can do it today without antirez's help. Really!

EDIT: online -> offline; typo.

This being a BSD product, they can just maintain and release their own version, and they're not even obliged to share their modifications with the community; they haven't in the past (e.g. BSD sockets, zlib) so I wouldn't expect them in this case either.

And as a paying microsoft custoemr, you should be getting such a service for your money.

Really, this is all it is about -- You, yread and microsoft are trying to get Antirez to provide valuable (to yourselves) service for free.

So, you can already run Redis on Windows, if you are so inclined. I too don't like using VMs to develop, and that's why I use Linux for my work environment, but, if you want to have a production-grade OS and be able to run Windows software, VMs are the only way.

That is a great philosophical question, and different people will have different answers, all valid; however:

> "Installing Linux boxes to run Redis", I can't help but feel he's being a bit narrow-minded.

..

> Why not just tell Linux users to get a Windows box if they want to run that software?

This is not a symmetric win32<->linux case. If you're a win user, and you need Redis, you can run it today, for free, starting 10 minutes from now (30 if you've never done this before and need to download stuff):

download oracle virtualbox; download ubuntu server install, install inside virtualbox inside ubuntu, sudo apt-get install redis-server

And really, that's all there is to it; if you are an experienced windows developer with no Linux experience whatsoever, this will take you all of 30 minutes (25 of which just waiting for downloads). It actually performs quite well; not as well as running directly on iron, but probably not more than 10% slower than a native port that does everything right (The current native ports are 100000% slower during syncing to disk)

If you're a linux user and you want to run a windows-only server, that costs your $100 or so for a retail win7 license, a few hours of downloading and 20-30 minutes of active setup last time I did that. Want to fire that up on 3 developer machines? That would be $200 more, thank you. Reconfigured your virtual box more than 5 times? You have to talk to Microsoft before you can proceed.

So, really, what he offers IS a viable solution for windows developers. Really. Try it before you consider it "narrow minded". You might find the narrow mindedness was not where you expected.

> In fact, lots of software starts out as Windows software and is ported to Linux.

The few I am aware of are picasa and 7zip, of which I only ever use the latter. Do you have more examples?

It's actually significantly harder to port Windows programs to Linux than the other way around, because the Win32 API has about 100 times more functions, and the standard practice (cheerfully supported and encouraged by Microsoft) is to use all of them.

I believe that thought is narrow-minded because you are not thinking in terms of enterprise. This would probably work in a startup, or maybe even in a mid-size business. But in an enterprise, going to your manager and asking to fire up a linux VM in a Microsoft shop will probably get you reprimanded (or laughed at). I would love to use linux all day, but we can't do it as there is no freedom to. With a Windows port, I could create a business case for it and get a VM provisioned with Windows Server on it within a short period of time. Honestly, as bad as this sounds, money for small things like Windows licenses is not an issue when it comes to enterprise.

Whoa whoa whoa. It's narrow minded to not dance around the narrow mindedness of others?

There is certainly a problem that needs solving here, but it's not Redis on windows.

And it's been very long since I've seen an "enterprise" that didn't already have linux deployments. Can you name a few?