Hacker News Reader

I think that multi platform code makes sense for many kind of software, mainly for client software (an email client, a browser, and torrent client), but Redis is useful in deployments, where the developer has control about what to run when deploying software, and Linux has the interesting feature of being free and open source.

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.

We use Redis quite a bit in one of our products, Kiln. Because Kiln is mainly a Mercurial hosting platform, we offer it as a hosted product on our servers or, for companies who would prefer to have tighter control of where their source code goes, as an installed product on our customer's servers. As Kiln is written in .Net, we require that users installing it use Windows. Asking our customers to also set up a separate %nix box (or VM), just to run Redis, is too much.

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.

I'm not bashing Fog Creek, you guys make cool products.

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.

Let me commend you on your solution; unlike the many complainers on this thread.

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's a shame you feel that way. I understand there is technical limitation due to the blocking nature of one of the subcomponents, but if Microsoft (or some other organization) solved that issue, it sounds like you'd continue mixing open source politics with your product development decisions which I would argue isn't conducive to more widespread adoption of the software or the health the software's ecosystem.

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.

Yes indeed, astonishingly, people do thing for reasons other than money.

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.

At times, antirez does appear to be a bit bone-headed. In the early days of redis (pre-1.0 I think) I (among several others) had sent him patches to incorporate unix domain socket support into redis server/client. Not to mention, the patches were summarily rejected by Salvatore. Google "unix socket redis" and you'll find numerous patches developed by several authors for redis 1.x - none of them made it into the official release.

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

Antirez, with this reasoning perhaps it makes sense for the official Redis project to support an official redis-cli (the command line client) for Windows.

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.

So probably all we need to do is to better link at the win32 ports from the download page... no need to make stuff official and merged into the main project IMHO.

It would be worthwhile investigating how the SQLite project approach this issue. I see a lot of parallels between the two projects.

Redis can be used for development on Windows. Other than that, people that are hosting software like Memcached, Apache, NGinx and PostgreSQL on Windows should be fired. If you're not up to it than you can always find other people to do it for you.

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.

"If you can't stand this situation you can always port it yourself, send a patch, etc, etc..."

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

Read the article - the author is saying that the same functionality provided is already implemented in a simpler and safer way.

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.

Surely any attempt to make code run under both POSIX and win32 is going to require adding more code and an abstraction layer?

More code and extra abstraction layers increase the cost of maintenance and even the cost of further developments, so when adding more code the benefits have to outweigh the increase in complexity. This is also the opinion given at the end of the article.

OK, I'm confused.

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.

Look, the author explains that the patch is incomplete, which I highlighted above and that it doesn't provide enough to the current functionality available already on Win32, but instead replaces a crucial component that has proven itself to work.

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.

Learning a different platform to a competent level is not really what you want to be doing when you're trying to implement production-ready systems under time and cost constraints.

BINGO.

Hence, he isn't.

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

My argument is more against the sentiment that could be summed up as "meh, just use Linux". What you say is absolutely fair enough, but should Microsoft (or other contributors) overcome the expressed limitations, then a promoted Windows port makes sense.

Redis is a server component you access through http. This means that there is no problem accessing a linux box running redis from a Windows (or whatever) application. So, really, the added value of a Windows port isn't very high, especially now that virtualization technologies are everywhere.

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

I have difficulty interpreting the difference between running a native process, and spinning up a VM (local or remote), as a trivial difference.

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.

If it's a desktop app, then you probably don't have serious enough load that you need the mainline version as opposed to the unofficial Win32 version. It's not like he's saying "If you run Redis on Windows I'll sue you," he's just saying, "I don't see enough benefit to it to accept it as part of the official Redis project, but I am 100% okay with other people working on it."

> I have difficulty interpreting the difference between running a native process, and spinning up a VM (local or remote), as a trivial difference.

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.

As I wrote, front-end software is a different matter. But if you want to create a desktop app, you probably just shouldn't use Redis - for sure this isn't what Redis was created for.

> should Microsoft (or other contributors) overcome the expressed limitations, then a promoted Windows port makes sense.

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.

It seems you missed the part he mentions there is already a Windows-compatible fork that's better than Microsoft's patch (equally unsuitable for production use, less changes to the original codebase).

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.

> If it were a valid argument, then why port any software to work under win32 at all?

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.

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

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.

"going to your manager and asking to fire up a linux VM in a Microsoft shop will probably get you reprimanded (or laughed at)"

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.

Why should antirez feel compelled to support Microsoft's enterprise customers without compensation at the cost of significant complexity? The incentives are all wrong.

I like it how "not catering for bureaucratic needs of the unpaying enterprise who has no problem paying Microsoft an others, even though there's a perfectly simple technical solution" is narrow minded.

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