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:
Microsoft team submits Redis patch to enable Windows support
81–90 of 103 posts
Re: Microsoft team submits Redis patch to enable Windows support
#82Earlier quoted context omitted.
Correct me if I'm wrong, but casting the result of malloc is generally considered bad form in C, isn't it?
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.
Re: Microsoft team submits Redis patch to enable Windows support
#83Earlier quoted context omitted.
It's really no wonder why people don't contribute to open source when this is the first response.
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 a…
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.
Re: Microsoft team submits Redis patch to enable Windows support
#84Earlier quoted context omitted.
That's a case for not merging, not for a parallel win32-based project - which this implementation could serve either of.
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. Microsoft wins and we lose on all scenari…
This is a very pessimistic view of the world and future events (which I don't share). I'd get that looked at.
A bad Redis port by Microsoft makes them look bad, whilst their endorsement of Redis makes Redis looks good.
The 'pro developers' that Redis attracts are going to be more than capable of identifying the culprit behind a shitty port.
Re: Microsoft team submits Redis patch to enable Windows support
#85Wow, 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 sugges…
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?
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.
Re: Microsoft team submits Redis patch to enable Windows support
#86Earlier quoted context omitted.
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? 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. O…
...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.
Re: Microsoft team submits Redis patch to enable Windows support
#87Earlier quoted context omitted.
I 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 ni…
no 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 ha…
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.
Re: Microsoft team submits Redis patch to enable Windows support
#88Earlier quoted context omitted.
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? 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. O…
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.
Anyway, antirez wrote a blog post explaining his position in a level-headed and reasonable tone: http://news.ycombinator.com/item?id=3333298
And it is indeed his call what to do with the patch. It is just a bit sad that there is this MS divide
Re: Microsoft team submits Redis patch to enable Windows support
#89Earlier quoted context omitted.
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.
He didn't say "Google is being mean", he said they and Apple were "suing everybody", a statement in no way supported by one of his references.
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"
Re: Microsoft team submits Redis patch to enable Windows support
#90Earlier quoted context omitted.
> 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. O…
...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).