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.
The 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.
> 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.
...nearly any office-scale printer you can buy runs Windows...
I'm positive I've read about multi-function office copier/printers that run Linux, but none of my search queries on Google and DDG yielded anything useful. I just got a bunch of pages of people asking for drivers.
oh, i'm sure they exist. there's no reason why a printer can't run linux. It's just that when most high end printers got UIs (mid to late 90s), Windows was the only decent dependable, supplier-backed option available, really. And since then the software evolved and thus stayed Windows-specific.
Similar reasons for why most other industrial / high-end professional devices run Windows. Effectively, Microsoft has locked in an entire industry (and as long as their developer support keeps kicking ass, few in the industry mind this).
Hmm. Most of the multifunction, networked printers I've had to deal with in small business offices run NetBSD. In fact, I don't think I've ever seen one that runs Windows. Of course, my experience is limited to only ~9 offices, but I just assumed they were all like that.
I'm coming from a very similar position (corun small bootstrapped startup running on windows server, outside the valley). In fact, my position is even worse, I want my software to run on my customer's servers. That's why the attitude shocked me.
Is your customer paying you? (I assume yes) Are you paying Antirez? (I assume no) Why is that attitude shocking you? You are paying Microsoft, and the only reason they want Redis to run on windows is so that you'll keep paying them. Not some grand "Oh redis is nice, we really want to support it".
> It is just a bit sad that there is this MS divide
And Microsoft is entirely to blame for it.
And cut the "Microsoft is a big company, don't treat it homogenously" bullsh@t. Barack Obama can't deport a us citizen he doesn't like (or at least couldn't until last week). Steve Ballmer can (and does) fire MS employees that are not aligned with his vision. There might be the occasional local initiatives that look nice -- but Microsoft is an enemy of free software.
First, to address your concern: You can just run your C# code on Linux, rather than Redis on Windows. Mono really is that good (unlike the Windows Posix subsystem, which -- had microsoft cared to maintain, would have been able to run Redis!), and cross platform requests go both ways. You'd also save money on server licenses.
I'm feeling like I need to get my karma downvoted today :)
I'm kind of amazed by responses from yourself and yread below.
You guys are paying Microsoft for the privilege of using their products. Microsoft is actively working to harm competitors such as Android, Linux, and (antirez's dev platform IIRC) OS/X every other day. It has actively worked to undermine the free software community (of which Redis is a product) for a long time, calling GPL "a cancer" (yes, I know redis is BSD), financing the frivolous SCO vs. Novell law suit, loading ISO committees against the Open Document Format, threatening VirtualDub with a patent lawsuit, and a hundred other similar things.
You are not paying antirez, but are getting an excellent product and service for free (the cost being taking 30 minutes of your time to run redis in vm! Really! Try! I set up Linux vms in linux for testing all the time).
And yet, when antirez says "meh, not interested, it goes against my focus", you call his response "bubble filtered" or (other posters) "immature".
An Upton Sinclair quote is extremely relevant here: "It is difficult to get a man to understand something, when his salary depends upon his not understanding it!"
I'm sorry, but I'm really not interested in the whole Linux vs Microsoft flamewar. It feels a bit last century, and, well, I doubt we'll be able to change each other's minds here.
Some small responses to some other points you made, though:
> And yet, when antirez says "meh, not interested, it goes against my focus", you call his response "bubble filtered"
Thanks for pulling me out of context. I also said, twice even, that it's his fair choice and I just wanted to give him a different point of view that maybe he's underexposed to. We're all in a filter bubble. Considering "you're bubble filtered" an insult feels a bit, well, naive to me.
> You guys are paying* Microsoft for the privilege of using their products. *
I'd pay for a Redis version on Windows.
> You can just run your C# code on Linux, rather than Redis on Windows. Mono really is that good.
I'd love to believe that, and in fact I'm absolutely baffled how non-sucky Mono really is given how little support it has gotten from both corporations (MS included) and the rest of the open source community ("yuck, Microsoft!"). It's really awesome, all the work they did there. However with the tech we're using (such as, for example, parts of .NET 4's Entity Framework), I doubt we'll be able to move to Mono soon.
> I'm sorry, but I'm really not interested in the whole Linux vs Microsoft flamewar.
Oh, how I wish it was a flamewar. You sir, are apparently willingly ignorant. I have listed many cases where Microsoft have actively harmed projects and community processes. Actions with documented, measurable economic harm. It does not become a flamewar just because you are not interested.
This is a business war. I consider the side you support (by virtue of paying them) unethical. If Microsoft "won" the war on free software earlier, e.g. SCO managed to discredit Linux to the point of no one using it, Redis would likely not have happened the way it did.
> I doubt we'll be able to change each other's minds here.
Agreed.
> Thanks for pulling me out of context.
I don't think I was pulling you out of context. The rest of your statement is basically "you're entitled to be bubble filtered". But his response was considerate, detailed, to the point, and certainly NOT ignoring the reality.
> "you're bubble filtered" an insult feels a bit, well, naive to me.
I understand it to mean "you're unaware because of the way you live your (professional) life". It isn't necessarily an insult, but it implies ignorance -- whereas antirez demonstrated the opposite. It's just out of line at that point of the discussion.
> I'd pay for a Redis version on Windows.
Make antirez an offer then, it might be worth his while if many people do that. If you don't have the cash (I'm running a startup myself, I know how that is), you can offer equity.
> However with the tech we're using (such as, for example, parts of .NET 4's Entity Framework), I doubt we'll be able to move to Mono soon.
Cool. Don't be surprised that your choice of platform and tools, e.g. the latest-and-greatest .NET 4 Entity Framework, limits your access to other tools, e.g. redis. Life is a tradeoff.
Hm yeah, it appears I am. I think you're actually right about that.
Have you come to this thread to bash anyone who "admits" to using Microsoft software? It feels like that to me.
I don't consider buying software from Microsoft to be "choosing a side", just like I don't consider buying Apple products to be choosing a side in the child labor wars, just like I don't consider buying a chocolate bar means I choose the side against slavery in Africa. If you're as hard-line as you demand, everybody becomes a hypocrite.
> Cool. Don't be surprised that your choice of platform and tools, e.g. the latest-and-greatest .NET 4 Entity Framework, limits your access to other tools, e.g. redis. Life is a tradeoff.
Completely true! Did I ever say anything to the contrary?
There's a big difference between "There are valid use cases for Redis on Windows" and "I demand that Antirez port Redis to Windows, now, for free". I really only made the former point, but I have the feeling that you're passionately ranting against the latter.
The 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.
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.
I would have upvoted this post, but for the last line. Much of Microsoft's past (and indeed some of its present) is tarnished with unfair competition through secret agreements, patents, etc., but there's probably a better way to express the resentment that has caused.
I 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.
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.
The snark on this thread is concerning, Microsoft has made a good gesture in trying improve the Redis story on Windows and IMO it's something we all should be encouraging as it can only serve to improve the Redis ecosystem.
Historically Microsoft hasn't been too fond of NoSQL but positive steps like this validates Redis in the eyes of Windows devs which has the potential to attract new devs to the world of Redis and NoSQL.
I personally hope to see this implementation improve so it runs flawlessly on Windows and Azure.
When on the other hand they are poisoning the Android/Linux ecosystem with FUD, patent extortion and the like. While I would prefer the discussion to stay civil and technical, Microsoft is consistently earning every snark they are receiving, and then some.
They might be doing other things you don't like, but at least give credit where credit is due.
Submitting code upstream to Redis is completely independent of their patent decisions regarding Android. I'm not a fan of their overall stance with respect to FOSS/Linux/Android, and they may be earning the snark there, but not in this case.
These discussions become a lot more valuable when we stop characterizing any organization, especially one as complex as a large corporation, as universally 'good' or 'bad'.
Sure. Just don't forget they profit from Windows sales and, thus, will do anything to justify the deployment of a Windows server instead of a Linux one. Including contributing to a Unix-native product. If, in the end, Redis' codebase becomes cluttered and performance and maintenance suffer, we all lose. I mean, all of us except Microsoft, who wins both by us losing and from gaining space for their own future offerings in this segment.
There is no good or bad. It's self interest. When their self-interest coincides with the society's, I'm for them. OTOH, it's been a long time since it last did. It certainly never happened after the mid 90's.
It would risk diverting attention from the Unix port to the Win32 one. Even if the Redis developers don't pay attention to this distraction, its mere existence fragments the codebase and creates two semi-compatible versions.
And if the Windows version sucks badly, any Windows user who tries to install it on Windows will end up blaming Redis and try something else. On Windows.
> These discussions become a lot more valuable when we stop characterizing any organization, especially one as complex as a large corporation, as universally 'good' or 'bad'.
That is true. But it is also foolish to ignore over 20 years of Microsoft's strategy, the mostly successful "embrace, extend and extinguish".
This patch is purely out of self interest: people might install a unix server if they want Redis and can't have it on Windows. There is no "good will" (and no "bad will").
If it harms performance on linux? Well, they are likely not to care at this point, or at least one second after the patch is accepted.
Microsoft has a history of co-operating with the rest of the world only when they are at a disadvantage, and ignoring standards and conventions when they have the advantage.
Excuse me if I'm not enthusiastic about a patch they send to a project I like.
> Submitting code upstream to Redis is completely independent of their patent decisions regarding Android. I'm not a fan of their overall stance with respect to FOSS/Linux/Android, and they may be earning the snark there, but not in this case.
Wrong. They are both cleared by the same legal department, guided by the same company vision. They are not being a useful member of the community. They're trying to give people less reason to leave Windows. Pure self interest, completely in line with everything else they do.
I dont want to defend Microsoft, but i think that if we dig deep enough we found bad "habits" in every big society:
what about Google[1] or Apple suing everybody from Samsung [2] to Luxembourgish restourants[3]?
Yes, but look at why Skyhook is suing them. We live in a weird bubble where if a company gets sued then they are the victim. No one even fathoms, when it comes to Google at least, that maybe they did something to deserve being sued.
sorry for my bad english, it led you to misinterpretations: I was citing situations in which other big names (not microsoft) were a bit "evil", google too (because the op was picturing a scenary in which Microsoft is all-bad with its FUD and google/android is just a victim)
I should have written "what about Google, intimidating its own partners in order to shut down competitors like skyhook, or Apple, suing dozens of society, from competitors to restaurants"
They were being sued by Skyhook because they were using Android compatibility tests "as a club to get OEMs to do what [they] want" (their words). In this case, they were using it to push out Skyhook in favour of Google Location Services.
- They don't allow to run your own programs on your own computer. Can you imagine Windows blocking Firefox? Microsoft was about to be disintegrated just for making a web browser, yet Apple can fully block competing programs.
- They are very expensive, so the great majority of world population can't use software made for Apple systems.
Don't confuse Microsoft's teams with the flatulating buttheads in the executive office. Most of the people working there now weren't around when MS was a dominant company.
2) The people working there are _taking orders_ from the executive office. You can be completely sure, especially in Microsoft, that this was cleared with the executive and legal time before anything was uploaded (not doing so is grounds for termination), and you can be quite sure that even if this is an "grass-root" initiative inside microsoft, it was discussed and authorized with management before the 3rd hour was spent.
More likely, someone in sales asked a customer "Why are you using Linux here instead of Windows?" and the response was "We need Redis" - prompting this work.
1) No they aren't.
2) Management was likely briefed, and someone indeed authorized it. However, if you believe this went all the way up to the likes of Ballmer, then you have no idea of the organizational structure of MS.
1) They still control 90% of the "Office / Productivity" software market; They just got below 50% in the web browser market, they're still above 90% of the operating systems market for personal computers (a category that includes desktops, laptops, but does not include tablets); And something like 20% of server o/s market.
How can one construe that as "not dominant", I don't know.
2) It doesn't go up to Ballmer (there are no "likes of ballmer" in MS - there is only Ballmer). But it got at least two levels below (which is a considerable number of levels up from a "grass roots" start, anywhere from 4 to 8).
[Edited for tone which I guess is the reason for the down votes. I appreciate the quick response below.]
Most of this patch is adding libuv, which is included in its entirety due to "the version included in the patch is different than the one available on github, some changes have been added to the code". There is also a lot of cleanup. Also a small nit, in the patch instructions:
3. make whatever changes needed to libuv as its own commit.
4. add libuv as a submodule to redis.
5. perform all the misc compiler cleanup stuff to redis as its own commit; usually you want your cleanup/refactored to happen before you perform functional changes.
6. add the ms-specific code as its own commit.
7. push up the new commits to the two forked repos.
This would make it all a bit easier to review. The only questionable part is adding libuv as a reddis submodule (4). Maybe I'd leave that part out initially and instead just specify the equivalent manual step needed there (clone our fork of libuv into X and checkout Y).
Not sure what they're going to do regarding fork, but they say this at the end of the gist:
TODO
Snapshotting (Fork and Write) is not perfect, right now we simply block requests while memory is dumped on disk. We are working on a solution that will give us better performance. An update will be released soon.
I wonder if they contacted Redis author before starting to work on this. You know, with the patch so big and radical, there's a possibility he doesn't even want to accept it.
What then, all this effort for basically nothing except a fork, which you then have to continue maintaining etc.
I wouldn't expect anyone to accept the patch in this state, but I hope that the "who cares about Windows" attitude dies and a dialog to get proper support into redis is started.
It's a shame that we're using an unofficial version on that platform right now.
You don't have to have a "who cares about Windows?" attitude to write programs that don't work on Windows; all you have to have is a "want to make the best use of Unix" attitude.
I would imagine they have activated "Compile as C++" for certain files. VC++ doesn't support C99, and it's probably easier to fix up any C++ incompatibilities than try to C89-ize everything.
I wouldn't so much call it "bad form" as just non-idiomatic. It doesn't really have big downsides in practice.
It's mostly a habit people pick up from C++ (where it's mandatory due to stricter typing), and if you want to build C code with a C++ compiler, you need to add the casts.
Given Microsoft's C++ fetish, I'm unsurprised by this.
I suppose one downside would be if you cast a voidptr to a pointer to (an element that has a different size), then calling operator++ moves it by more than if you had left it as a voidptr.
"Do not use the following reserved device names for the name of a file:
CON, PRN, AUX, NUL, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, and LPT9. Also avoid these names followed immediately by an extension; for example, NUL.txt is not recommended."[1]
I once saw some interesting behavior on a Windows 95 machine - my brother printed a drawing for a convention to a file. The printer was a HP LaserJet with plug in module that enabled Postscript. He named the file "con" and when he hit OK on the print dialog the entire screen buffer (over the windowing interface) started filling with Postscript.
Windows tries to prevent you naming a file "con". I once renamed a text file con in Win95; using a raw disk editor to change the file entry and it did this too - every time I saved text in the file it would write it console/DOS style to the screen.
We're encountered this issue when dealing with ETF tickers. We use Linux but a 3rd-party redistributor was on Windows; the reports we created had file names in the form <TICKER>.pdf and, what would you know, PRN.pdf caused all sorts of trouble for them...
You can't have files named like the old DOS devices: CON, LPT, AUX, PRN etc. This is originaly due to CP/M backwards compatibility, it didn't have directories so magic files were udde to pipe stuff to printers and other devices.
PC-DOS inherited it from CP/M 80. Windows was built at first on top of it and then replaced it in stages. I have no idea why would this still be present in the current codebase. It would probably be easier just to fix the filesystem.
There's countless batch files that rely on NUL (including with extensions, usually because some other batch file is appending the extension). Most of the other ones could probably be safely removed, but it would still run contrary to Microsoft's policy of not breaking backwards compatibility unless absolutely necessary.
I'm way behind on Windows tech, but it's made a token attempt to support a crippled POSIX subsystem since Windows NT. This is supposed to be the modern equivalent:
Look at the instructions to create a branch out of a commit.
Just
git checkout -b 2.4_win_uv 3fac86ff1d
would have sufficed
Instead, they give a mini git tutorial.
This comment is not a taunt at MS. Just that they have tried to learn git and the process, given that git now has a very good implementation on Windows and since they are trying to do something similar here - bringing Redis to Windows - it doesn't look good.
And if someone previously uninvolved with your work showed up one day and dumped a few weeks of a teams work in your lap in one giant patch that affected most of your codebase, you'd say thanks and look to merging it in rather than talk about proper process?
Most projects have a process and gigantic monolithic patches that include entire new projects and "cleanup" updates to core all wrapped up in one are unmanaged and unmergable. It's for the sake of process.
Of course I'd prefer they work in a way which meshes with existing process, but I'm not going to act dismissive and sigh if someone goes another way. If someone removed the GIL from CPython and gave me a context diff, for one I would barely be able to read that format, but I'd find a way to make it work.
Pull requests are great, but it's not like someone couldn't apply the patch and give them a hand - earlier in the thread someone did just that.
they probably mainly want feedback from the project maintainers at this stage, and the project maintainers can apply a patch just about as easily as they could apply a pull request. (It's so big that the web view isn't likely to be useful.) Also this will probably be going into a new branch if anywhere, so does a pull request to an existing branch (which is all that's possible AFAIK) even make sense?
can someone please submit a patch to MS to add git pull support to team foundation server or visual sourcesafe (or what are MS guys using these days as version control?)
I think they use Perforce (or at least, a heavily patched version they can "Source Depot"). That might have changed since Team Foundation was brought out. I don't think they ever used visual sourcesafe.
I'm in Office and we currently use Source Depot, which is a modified version of Perforce. We have so many tools that interoperate with it (and everyone knows how it works) that I don't see us moving away from SD anytime soon.
We use Team Foundation for a few other things related to project management (personally, I'm not a fan), but not for source control.
Spent the time on doing such big patch, and not spend the time on learning (5 min max) how to do a pull request... make me think they were forced to do this kind of thing.
So once the code is in, no maintainer from microsoft will be.
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.