Hacker News new | ask | show | jobs
by ergo98 5841 days ago
It's unfortunate there are no Windows binaries (well apparently there are no binaries yet period, but I mean they don't plan on binaries until some time out). We could host Linux VMs, but ideally we just run Windows binaries and get rid of the abstraction.

That is the case for a large number of these products. At best offering a terrible Cygwin port. In the Windows world the premiere product right now is the beta of AppFabric, but almost no one uses that and it has an absurd list of dependencies that preclude many uses.
2 comments
siculars 5841 days ago
Your post is just another nail in the MS coffin. The simple fact is that the latest, greatest hotness is just not playing in the MS ecosystem. Virtually all NoSQL systems support windows as an afterthought if at all. Not to mention hotness like nodejs.

The bottom line is that the people who make the new shinnies just don't play on MS boxes and could care less if their toys ever play on MS boxes. No, I'm not talking 'enterprise'.

link
wmf 5841 days ago
Porting software to a completely different culture isn't cheap and there's little incentive for volunteer open source projects to do it. If enough software that you want isn't available on Windows, it's probably cheaper for you to learn Unix.
link
henrikschroder 5841 days ago
There's plenty of people that want to volunteer porting projects to Windows, there are other hurdles such as Microsoft refusing to ship a C99 compiler, and getting the Windows port accepted into the main repo for the project.
link
mahmud 5841 days ago
Huh? Everyone builds with mingw. We shipped pure win32 desktop and service apps that were compiled with mingw.

The difficulties in porting to Windows are slightly more technical than just the availability of a free C compiler with C99 support, and project management politics.

link
henrikschroder 5841 days ago
The problem is that MingW is a completely alien environment for the vast majority of C developers on Windows, and Visual Studio is a completely alien environment for POSIX projects.

That way you can't use the majority of Windows C developers, many of whom would love to contribute to open source projects, and who has the knowledge of the technical difficulties of porting to Windows.

link
ergo98 5841 days ago
Where did I say I didn't know Unix? The problem is that for some deployed solutions adding in Linux boxes simply because they host one piece of software isn't optimal, so "native" solutions are chosen instead. We aren't talking about a product that is tightly coupled with the OS (or at least it shouldn't be).
link
jbooth 5841 days ago
It should be, actually, if it's going to be fast. Memcached is fast because it optimizes interaction with the I/O layers -- you can't stay portable if you do that.

EDIT: Actually, you can use libevent for some subset of these cases and get speed+portability, but I'm pretty sure memcached predates libevent by quite a bit so they're not. So there's your answer.

link
JoachimSchipper 5841 days ago
The first commit to memcached on github is http://github.com/memcached/memcached/tree/32f382b605b4565bd..., which uses libevent. libevent has been around for a while...
link
silentbicycle 5841 days ago
Memcached predates github by quite a bit, actually. It was originally made as a caching layer for livejournal, and IIRC was made in the early half of the 00s. (Having a hard time finding an exact date, though.)
link
dlsspy 5841 days ago
If you want to know the exact date, look at the link you're suggesting is wrong.
link
reynolds 5841 days ago
memcached actually uses libevent.

Edit: oops, JoachimSchipper beat me to it

link