6 ms·
Wow, I'm kind of surprised by the amount of snark ("eww it's 140k lines", "mini git tutorial", "patch file instead of pull request"). It seems it's so big beca
by yread 15y ago
Wow, I'm kind of surprised by the amount of snark ("eww it's 140k lines", "mini git tutorial", "patch file instead of pull request").
It seems it's so big because it contains the libuv. The instructions to compile on Windows don't seem trivial at all and if I cared enough to try this I would appreciate that they wrote it step-by-step.
The guys at MS just sat down and made it work while antirez was throwing out suggestions how to make it work with " the behavior of the window filesystem is so incredibly broken that well they should really fix it I guess"
Sorry for the rant I would just expect better from the community.
- to3m 15y agoI couldn't be bothered with writing a rant, so I'm glad somebody put the effort in. You're right... it's a bit off. Just a chance for people to feel superior over the Windoze lusers, I guess :) I trust that the people behind the patch have got from it what they want, and that if the patch is just sent straight to the recycle bin then it will be no skin off their collective noses.
- deleted 15y ago[deleted]
- manojlds 15y agoI mentioned the mini git tutorial I am a MS fan and I use msysgit on Windows. My point being, git now has good enough implementation on Windows and the team should have taken the time to learn it, as in this context, it doesn't look good that they are ignorant of git.
- antirez 15y agoThe patch provided does not handle persistence correctly (saving blocks), does not make tests passing. The "libuv" part was the trivial part, already solved by the community, see the unofficial win32/win64 port that fixed it natively, with less code. So nice to see Microsoft contributing code to Redis, but this is not a production ready port and is practically equivalent to what we already had made by the community. Also, what is the point on having a production quality Redis server on Windows? That it will slow down the Redis POSIX development if we merge the two projects, the WIN32 API is different, there is a lot of care needed to maintain a port, but what is the real gain? Even services based on Windows like Stack Overflow had no issues running their Linux boxes to use Redis. I've the bad habit of doing the interest of the Redis community, so once I saw there was a reasonable port of Redis for win32 (that is, enough to code under Windows and test stuff, no production ready) I avoided additional efforts in this regard to provide more value in the "real" Redis, the one running where 99.99% of people need it to run well, under POSIX environments. EDIT: I was not clear in this post about what I'll do. I'll not merge the patch, but I'll see with interest the creation of a "redis-win32" project that has a different repository, different issues page, and so forth, and is not officially supported by me. But I'll be happy to provide a page in the redis.io site about it, to link at the project, to collaborate with the developers, and so forth.
- skrebbel 15y ago> Also, what is the point on having a production quality Redis server on Windows? I (co-)run a small bootstrapped startup running on a Windows server. We're considering to use Redis as our primary (only) database. For us, the simple ability to run Redis and our main C# application on the same box, in the beginning, would be a big plus. It simply saves a server, and unifies our production environment to a single OS. Of course, it's just something relevant in the very beginning, and probably only for the non-valley-super-funded kind of startups. But it's this kind of stuff that might make us change our minds about Redis; if we can avoid doing system administration on two different OS'es for the time being, plus avoid installing two servers per application instance, then that's really a big plus for us. It allows us more time for functionality and less time for all kinds of admin scripting and whatnot. Of course, you could reason that we should simply switch off Windows entirely, but we really like C# and Visual Studio and we're productive in it. Also, it'd be great to be able to develop against a more "official" version of Redis then what we have now. Note, I'm not at all telling you what to do. I'm just giving you an idea why maybe it is useful to consider supporting Windows, using my personal situation as an example. Not every startup chooses Ruby or Node. Not every developer prefers a Mac. For the same reason I also humbly doubt the 99.99% number you quote. I think if you'd move to support Windows better, that number would decrease because organisations and people who run on Windows will now often simply disregard Redis as an option. Especially corporate environments (business IT for instance) are usually very heavily Windows-based. The same holds for nearly the entire "high tech" industry (software for machines, devices, factory lines - e.g. nearly any office-scale printer you can buy runs Windows, nearly all factory management (MES/SCADA) software is Windows-based, etc.). These are industries that could benefit a lot from the performance increases Redis could give them (by using it essentially in the same way as stackoverflow does). My bet is they'd often be reluctant to even consider it if it means training an entire sysadmin force for a new OS. And that's even disregarding the software vendors who (so oldschool) sell software installed by clients (f.ex. the factory line stuff). They want to make their software faster, they don't want to force their client to administrate an extra OS. Once again: not telling you what to do, it's your call (and I'm thankful for Redis no matter what). I'm just saying: mind the big jolly POSIX filter bubble; there's a big, big world out there, and a lot of it is very much not POSIX.
- Legion 15y agoI think patch versus pull request is a valid complaint, but there's absolutely no reason to be snarky about it. Everything else just reeks of MS bashing that reinforces the negative view of the open source crowd that many on the MS side of the divide have. Github is looking to pull the Windows crowd into their world; on the blog, they stated that as an explicit goal for their hiring of Phil Haack. So, please, play nice. I would much rather Github stay a fairly harmonious place than be another open source vs. MS battleground.
- jf 15y ago> So, please, play nice. Working on it. Microsoft is a big company.
- burgerbrain 15y agoThe complaint about the size is most certainly not just "MS bashing". Dumping massive flawed pieces of code on people out of the blue and expecting them to be grateful is bad form, no matter who you are. Unfortunately this seems to be Microsoft's MO.
- Gigablah 15y agoHow are the MS people who submitted the patch "expecting" others to be "grateful"?
- burgerbrain 15y agoPerhaps they are not, but the people complaining about "snark" are what I am talking about. Anyway, my point is that complaints about the size are very valid.
- moe 15y agono reason to be snarky Really? Until very recently Microsoft did actively fight the OSS movement with claws and teeth. Now they suddenly embrace us and we're not even allowed to be snarky? Sentiments aside; as Antirez points out, supporting a win32-port would be a ball on a chain. If Microsoft really suddenly wants to be friends then they should step up and maintain a fork on their own budget instead of throwing a half-baked patch on the floor and expecting someone else to gift ongoing support to a for-profit company. Otherwise, in my very personal opinion, they can just go to hell.
- blhack 15y agoIf anybody, like me, was curious what a "pull request" is[1]: You fork the repo, submit a patch to that, then ask that the maintainer(s) of the original repo "pull" your code into theirs. [1]http://help.github.com/send-pull-requests/ http://help.github.com/send-pull-requests/