
Redis for win32 and the Microsoft patch - antirez
http://antirez.com/post/redis-win32-msft-patch.html
======
skrebbel
Antirez makes the point that linux has won the SW deployment war. And, really,
it hasn't, with the possible exception of web startups. A lot of software
isn't standard SaaS web stuff, and a lot of software won't for a long time,
for all kinds of practical reasons.

Antirez, if you could try and imagine how Redis could be used in different
environments (inside devices, as a component in 'end-user' business software,
and so on), you might see why 'deployment' and 'servers' and 'the cloud' is
not at all the only area where Redis might shine. It's your project so your
choice, but don't neglect industries and areas simply because those involved
in it aren't so represented among your twitter followers!

~~~
beagle3
Could you help me imagine how Redis can be used inside devices, or as a
component in 'end-user' business business software? (unless it employs a
"server").

Redis does one small thing and does it amazingly well -- an in-memory database
with persistence and some very useful operations (such as FIFO lists) that do
not need roundtrips.

That does not make sense inside a device unless you have ridiculous amounts of
RAM to spare (which has never been the case in my experience).

Similarly, it makes very little sense in an "end-user" business software,
unless there are _multiple_ processes needing access to the same in-memory
data. And that (to me) means a "server" is going to appear sooner or later.

Really, unless you run it on a "server", then sqlite with properly set cache
parameters is almost surely a better choice, and works on Win32 since 2002 or
so.

Where it makes sense to deploy Redis, looks to me like antirez is right and
Unix has won. And even though Redis likely works on iOS and Android out of the
box, it makes no sense to do so, at least not at this point.

~~~
skrebbel
> _Could you help me imagine how Redis can be used inside devices, or as a
> component in 'end-user' business business software? (unless it employs a
> "server")._

Not all devices are phone-like end-user devices.

I can imagine a machine that produces something. It is full of sensors and
actuators, plus logic that uses sensor input to compute what the actuators
most be doing. Typically one would store some recent sensor + actuator
decision data in RAM to calculate averages, do all kinds of computations, etc.

Storing the same data in Redis instead gives you all that, but persistence for
free. That's great, because it means developers / maintenance people / support
people can always get a decent dump of what recently happened, without much
overhead or extra work. The memory is the log. Elegant!

Computer systems that control factory processes, such as SCADA and MES
systems, often have to deal with large amounts of data coming in from many
different machines. Most vendors therefore wrote what they call a "real-time
database", even though it is not really real-time, just fast. Redis would be a
great substitute for such a database.

A high-performance multifunctional office printer has a large memory of jobs
sent to it by many different people; print jobs, scan jobs, and so on. These
often incorporate fair amounts of data, but the data processing speed
requirements are very high because the printer is so ridiculously fast. I
imagine that right now the entire job data structure is effectively held in
memory and hand-persisted just in case the printer fails; people wouldn't want
to lose their print jobs, would they? Persisting data that must be held in RAM
for performance reasons. Hmm, where have I heard that before?

I'm not saying Redis is the ideal choice for these particular cases. I'm just
quickly braindumping some examples.

I must admit I can't come up with a great end-user business SW example right
now though. Maybe I was off the mark there.

That said, as more business applications are moving to the web too, Redis
would be very much applicable there. Many organisations (think offices,
services sector) have their entire custom-built internal IT systems based on
Windows. Much of this is probably a relic of the vendor lock-in practices that
MS was very effective with a decade ago, but they're still there and as MS
keeps supplying excellent dev tooling, it's unlikely to go away any time soon.
Imagine a team of 10 sysadmins for a 3000 person company all highly skilled in
administering Windows systems. Moving such people to Linux "just" to
administer a Redis installation is impractical, and the company will rather
disregard Redis for other options.

~~~
beagle3
All these cases you describe are stand alone systems and could equally well be
running Linux, or running it in a virtual machine.

I should have asked "inside devices _running windows_ , or as a component in
'end-user' business software _running windows_ " I thought that was implied
given the context.

Specifically about printers - they're not _that_ fast that sqlite or postgres
can't deal with them. Really. redis is for the 50MB/sec pushing-things-around
speed. Fastest printers are at the 10MB/sec, which MSSQL, PosgreSQL and SQLite
handle perfectly well. Also, redis is about lots (hundreds of millions) of
small items. printers are about few (thousands) of large items.

> Computer systems that control factory processes, such as SCADA and MES
> systems, often have to deal with large amounts of data coming in from many
> different machines. Most vendors therefore wrote what they call a "real-time
> database", even though it is not really real-time, just fast. Redis would be
> a great substitute for such a database.

They should pay for a "real" in memory databsae if they can pay for windows.
TimesTen, Sybase IQ, Kx. Yes virginia, there are consequences to using the
proprietary eco-system.

> Imagine a team of 10 sysadmins for a 3000 person company all highly skilled
> in administering Windows systems. Moving such people to Linux "just" to
> administer a Redis installation is impractical, and the company will rather
> disregard Redis for other options.

You're spending $1M/year in sysadmin salary alone here - probably $1M/year
more on hardware and other licenses. Shell out $50K for TimesTen and be done
with it. Or pay someone (possibly even antirez) who'll produce a windows port.
If it's not worth $50K to this company, it's not worth even a single minute of
antirez' time.

~~~
skrebbel
all these devices could run Linux, yes. All webapps could run on Windows, too.
But as POSIX won the webapp server war, Windows won the expensive machine war.

also, you seem to very much want me to demand that antirez codes a windows
port, for free, pronto. i never asked for anything like that. i was, and still
am, only referring to antirez's conclusion that POSIX is the 99.99% platform
for all places where Redis could the best fitting option. I was hoping for him
to slightly adjust that conclusion. What he does with it afterwards is
_entirely_ up to him.

~~~
beagle3
> Also, you seem to very much want me to demand that antirez codes a windows
> port, for free, pronto.

I apologize for implying that if I did. That was not my intention.

~~~
skrebbel
Oh! I appreciate the apology. Very much, in fact. Also, if you felt I was rude
back to you at some point, please know that I did not intend for that either.

(offtopic) Really, it's this stuff that keeps me on HN. The ability to shake
hands and move on is quite seldom on internet forums.

------
axefrog
Plenty of developers learn a specific platform and are comfortable using that
platform, setting it up and know the ins and outs of securing it. Yes, yes of
course they should _learn_ the other platform but really if you're trying to
get a job done, you want to be sure you know what you're doing. 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.

So when he says "even if you want to run your code under win32 systems what's
wrong about installing Linux boxes to run Redis", I can't help but feel he's
being a bit narrow-minded. If it were a valid argument, then why port any
software to work under win32 at all? Why bother with node.exe? Why bother with
Windows implementations of MySQL, MongoDB or PostgreSQL?

In fact, lots of software starts out as Windows software and is ported to
Linux. Why not just tell Linux users to get a Windows box if they want to run
that software? I would suggest that the author revisit this viewpoint and
consider why the majority of products with which he competes have chosen the
platform-agnosticism route.

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

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

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

------
shin_lao
_I don't think Redis running under win32 is a very important feature. It is
cool to have a win32 port that can be used for testing, as we had before, and
as we have in a different implementation thanks to the Microsoft patch, so
developers using Windows can easily test Redis and develop their projects. But
what is the point in providing a production quality win32 port?_

Roughly 60% of our customers run Windows servers in production (2003 or 2008)
which is why we support Windows as a first citizen platform. These customers
have no desire to run Linux boxes for various reasons and we would simply lose
deals if we didn't support their environment.

We've managed to deliver the same level of performance for all platforms we
support, and although our NoSQL product is very different from Redis I think
you could fully support Windows if you wanted to.

Additionally, I know from experience that supporting multi-platform greatly
increases the code quality and robustness. Obscure race conditions or memory
problems may be revealed by such support.

Nevertheless, adding support for a platform _a posteriori_ is a huge task and
you have the right to consider it's not worth it.

~~~
FooBarWidget
If code quality is your concern then supporting multiple Unix variants already
does a good job at revealing bugs. Supporting Windows _and_ Unix is a whole
different beast. They're so radically different that you're essentially
writing two different versions of the code. And since all abstractions are
leaky, fixing a bug that occurs on Windows may not fix a bug on Unix; it may
even introduce a bug in Unix.

~~~
shin_lao
There is already a huge amount of libraries that abstract the hard part for
you. 95% of our C++ code isn't platform specific and we support FreeBSD, Linux
and Windows.

~~~
nknight
I've never used a non-trivial piece of cross-platform software that didn't
have significant platform-specific bugs. If you're claiming yours doesn't, I'm
going to have to ask for access to your customer support email...

~~~
shin_lao
We did have platform-specific bugs, but the fixes (if any) were not platform-
specific.

In other words, we change the code so that it fixes the platform specific bug
while adding no platform-specific code.

(Don't know if I made myself clear).

------
antirez
I just linked the two win32 ports to the project download page:
<http://redis.io/download> this will hopefully expose the two efforts more and
may result if there is a real community around it into a redis-win32 project
to mature.

------
pgroves
As a Linux user who keeps a Windows desktop around just for Netflix and Steam,
I find this deeply (and devilishly) satisfying. Telling people they're
platform isn't supported because it's just not an important enough market is
something I've been hearing for over a decade now.

MS coming out the message "but...but...but...you should support everybody!" is
a bit of a pot/kettle situation and I hope they are treated with the same
passive-aggressive apathy as they treated Linux and Mac users for all those
years.

I know I'm being petty but I can't seem to make myself stop smiling.

~~~
protomyth
I would have hoped we all know how we felt and try not to do the same things
Microsoft did. What comes around goes around and I really don't want to be on
the receiving end again.

~~~
beagle3
> he same things Microsoft did.

Are still doing.

> What comes around goes around and I really don't want to be on the receiving
> end again.

You're still on the receiving end. And "what comes around goes around" is
simply what's happening to Microsoft in this case.

~~~
generalk
Let's be fair though -- Microsoft went ahead and grabbed the open-source code
and provided a patch that makes it mostly work under WinAPI. In my book,
that's pretty decent behavior.

~~~
beagle3
> In my book, that's pretty decent behavior.

I'd reserve judgment about this specific case until we see how things actually
turn out.

I've been dealing with Microsoft for more than twenty years, and I'm not
holding my breath for their decent behavior, although it happen occasionally.

------
slig
Here's possible outcome:

\- Half-assed port for windows appears, with a big "NOT SUITABLE FOR
PRODUCTION";

\- Clueless programmers will simple google "redis windows", hit the first
compiled version "redis.exe" and use it, eventually shipping it to production;

\- They'll then hit the official support forums and SO with "Redis doesn't
work!!"

------
va_coder
I find little sympathy for the MS world.

How about a port of IE to Linux so I can test websites with it? How about the
ability to install multiple versions of IE on Windows? I could go on....

~~~
est
IE relies on mshtml which relies on COM which is basically, well, core Win32.
IE is also the largest OLE container.

~~~
MichaelGG
But that was a decision they deliberately took. At one point, IE had versions
for UNIX and Mac.

------
lhaussknecht
I'd really appreciate a supported Windows version. We are a MS shop and nobody
want's to administrate a linux box here.

It would be cool to have a VMWare Virtual Appliance Ready to go. Shouldn't be
too hard since Redis is sponsored by VMware ;)

------
blub
I am not very familiar with webscale databases like this, but the reason for
rejecting the patch is weak. I mean "even if you want to run your code under
win32 systems what's wrong about installing Linux boxes to run Redis?".

This is simply missing the point of cross-platform software...

~~~
mythz
You're missing the point of developing highly-tuned, quality, production-based
server software. Redis is not you're average Java/.NET user-level application,
it's one of the fastest NoSQL solutions in existence.

@antirez wants to take advantage of the underlying POSIX platform and as such
Redis takes advantage of unique features only available on *nix. His point is
merging the patch increases the size and complexity of the project (whilst
reducing stability) - detracts from his mission of making Redis run
exceptionally well on POSIX platforms.

He also highlights that Windows/.NET shops like StackOverflow have no problem
setting aside linux servers to run host Redis servers in production.

~~~
coffeemug
Quake is one of the most highly-tuned, quality, production high-performance
software, and it runs on tons of platforms from Linux, to Windows, to even an
iPad. High performance software is not incompatible with portability.

Redis's performance (compared to traditional databases) comes from the fact
that the data structures are maintained in memory, which turns out to be a
really good tradeoff when your data set is small. That has nothing to do with
POSIX, or unix. The point of contention is the fact that Windows does not have
an efficient implementation of _fork_ , which enables copy-on-write semantics.
Redis uses that to periodically dump data to disk without blocking the
original process. This is a really clever use of a feature unique to unix, but
one man's cleverness is another man's limitation.

Building cross platform software really forces you to examine your
architectural decisions, learn about other platforms (and by extension, the
limitations of your own), and your software always ends up having a better
architecture when you're done with the porting process (in addition to being
usable by more people).

@antirez's arguments regarding complexity, additional testing, etc. make total
sense, but your performance/stability argument doesn't hold water.

~~~
buff-a
Quake? This quake? <http://en.wikipedia.org/wiki/Quake_(video_game)>

What a wonderful argument in _support_ of @antirez's suggestion that other
people port and maintain it. In _every_ case each port was done after the
fact, into its own project. They may since have been reintegrated back as part
of the source release (5 years later). But the core team certainly didn't do
it. Carmack ported Quake to GL in '96 and IIRC that was used for a linux port.
Again, not on main branch, not being committed while the team was working
Quake 2.

I've made cross platform video games and I don't find your opinion remotely
credible. I've also ported video games from one platform to another. A game
that was highly optimized for one platform required a complete rewrite of the
graphics engine for the other. Companies like Naughty Dog and Insomniac, that
can focus on a single platform, have a much easier time of it.

------
wpeterson
Unless you're using Microsoft servers/tools like .NET, this is another nail in
the coffin as Windows machines as a viable platform for most web-development.

I spent the first year of my Rails development on Windows and it was so
painful - slower, strange bugs, many unsupported tools/libraries.

This seems like a reasonable decision, but one in a long list of reasons you
can't easily develop on Windows unless you're targeting a Microsoft stack for
your product.

~~~
untog
Yes and no. I sometimes develop in Windows (I find the UI easier to work with
than OS X or Linux, just a personal preference) and I just run all the server-
side tools I need in a tiny Linux VirtualBox VM.

It's an ideal setup, really- when I'm done with development and watch to kick
back and watch a movie, I just put the VM into sleep mode and kill off those
background tasks.

------
moondowner
Totally right blog post from antirez, I agree with him as for his plans to his
attitude.

------
rudiger
How's the performance of Redis when it's running in a Linux VM?

------
nknight
The fundamental problem people are having seems to be "antirez won't support
Windows".

Let's say BigCorp really wants to use Redis, but only supports Windows.

Why is it OK for them to ask antirez to support Windows, but not OK for
antirez to ask them to support Linux/POSIX?

Don't go with a kneejerk response, think about it.

Neither party in this relationship has any special obligation to the other,
there's no contract, no money is changing hands.

BigCorp wants antirez to support their preferred software (Windows), antirez
wants BigCorp to support his (Linux and/or POSIX).

It will cost BigCorp more to support POSIX, you might say. But cost them more
relative to what? Of their tens of thousands of employees, billions in
revenue, BigCorp would be dedicating an infinitesimal fraction of its
resources to supporting a POSIX-compatible OS.

Meanwhile, a huge fraction of antirez's time will be spent dealing with the
effects of trying to maintain a high-performance, low-level datastore on two
utterly incompatible platforms, and the time he spends on that is time taken
away from work on other bugs and features, which also amounts to time taken
away from all the people who already use Redis on POSIX.

There is no incentive at all for antirez, his employer VMware, or the Redis
community at large to go through the pain of integrating Windows support into
Redis mainline. There is some incentive for BigCorp to support Linux, since
they want to use Redis effectively.

The incentivization is exactly backwards, so it should surprise absolutely no
one that antirez isn't prepared to deal with supporting Windows.

~~~
angersock
So, let's talk about the incentivization issue first.

 _Why is it OK for them to ask antirez to support Windows, but not OK for
antirez to ask them to support Linux/POSIX?_

Because antirez has a tool whereas BigCorp presumably has a problem. Because
all of us could benefit from this, while only some of us might benefit from
BigCorp switching to Linux.

Asking somebody to make their tool more available is, I posit, much more
reasonable than asking somebody to change their problems.

BigCorp has potentially hundreds of thousands tied up in existing equipment,
IT infrastructure, and training for employees. You and I might not flinch at
spinning up a VM to run a database, but we (and the rest of the HN community!)
should not fool ourselves into thinking that this is in any way always
appropriate for a company.

 _Meanwhile, a huge fraction of antirez's time will be spent dealing with the
effects of trying to maintain a high-performance, low-level datastore on two
utterly incompatible platforms, and the time he spends on that is time taken
away from work on other bugs and features, which also amounts to time taken
away from all the people who already use Redis on POSIX._

Or, you know, he might talk with the Microsoft development team and try to get
them to take over maintenance of the Microsoft codebase, and clean up the
platform-specific architecture that gets in the way--and in so doing, write
better code.

If you can't/won't write platform-independent code, you are either lazy or
your problem domain is heavily dependent on your platform. As far as I know,
in-memory key/value stores aren't a Linux-specific problem, so...

<rant> _There is no incentive at all for antirez, his employer VMware, or the
Redis community at large to go through the pain of integrating Windows support
into Redis mainline._

Let's look past incentives here. Let's talk about Doing the Right Thing.

A huge number of people here make daily use of software packages and stacks
that are open source. We owe our livelihoods to the folks that have been kind
enough to release the source to their programs and, more importantly, work
with the community to improve their code.

We owe it to ourselves and our community to call out people being lazy and
selfish, and letting politics overrule sound engineering and decency.

This is an unreasonable decision by antirez. He's got a cool framework. He's
got a bunch of code and (presumably) people that are happy to work with him on
making it even more useful.

He's also not going for it, because "use linux lol". Not because it's hard,
not because he doesn't have folks that can add it, not because the problem
extends beyond some refactoring and #ifdefs and makefiles.

Because he's lazy. Because Linux is the One True Way. Because helping out
anyone who can't just change their infrastructure on a whim is too much to
ask.

Really folks? You don't see a problem with this? </rant>

~~~
tptacek
Guy writes code for Linux. Code could theoretically be made to work on
Windows. Windows users are therefore entitled to a Windows port.

That's roughly your argument here; I've just done you the favor of adding
concision to it. The motivations of all the parties involved, enterprise IT
costs, all that jazz, none of that matters. Fundamentally you're saying "if
something can be made cross-platform, it's wrong not to make it cross-
platform".

That is, to say the least, a comical argument coming from people who want
_Linux_ code deployed on _Windows_.

~~~
angersock
_Guy writes code for Linux. Code could theoretically be made to work on
Windows. Windows users are therefore entitled to a Windows port._

Not quite.

Guy writes code for Linux. Code could theoretically be made to work on
Windows. Microsoft team submits patch to achieve this functionality. Users can
reasonably expect a Windows port. Guy decides using submitted code is too much
effort (from article says will get harder and harder) and that besides, there
is no demand for it (from article: "I don't think Redis running under win32 is
a very important feature."). Users have been denied functioning code because
of arbitrary decision by guy.

~~~
tptacek
You wrote (and I numbered):

 _(1) Guy writes code for Linux. (2) Code could theoretically be made to work
on Windows. (3) Microsoft team submits patch to achieve this functionality.
(4) Users can reasonably expect a Windows port. (5) Guy decides using
submitted code is too much effort (from article says will get harder and
harder) and that besides, there is no demand for it (from article: "I don't
think Redis running under win32 is a very important feature."). (6) Users have
been denied functioning code because of arbitrary decision by guy._

(4) simply does not follow from (1), (2), and (3), derailing the whole rest of
your argument.

Salvatore doesn't owe anyone a damn thing. He has _the opposite_ of set the
expectation that there will ever be a Windows port, so any user who thinks
they can "reasonably expect one" is delusional.

Anyone who says otherwise is arguing for the sake of arguing. Writing a
program _specifically for Unix_ is obviously a totally reasonable thing to do,
just as it makes zero sense to demand Panic provide a Windows port for
Transmit, or that Microsoft provide IIS7 for FreeBSD.

~~~
angersock
If I'm not mistaken, 4 actually very much does follow from the preceding
points.

The code is brought into existence. Code is observed to be capable of being
modified into working on Windows (i.e., nothing radically platform-centric
about it). Microsoft provides the grunt work to accomplish a patch that proves
this observation true.

Very much, by definition, users can reasonably expect a Windows port. The
capability exists. The code exists. The patch functions. If Windows User
Clippy says "I expect that redis will be ported to Windows, given these
facts", Clippy is not being unreasonable.

I'm sorry, but to claim otherwise is merely being obtuse.

Your points about IIS7 and Transmit are correct, as those rely on specific OS
functionality that is unique--the constructs Redis uses are not, and again
code has been written to show this fact.

Now, there very much is something to be said for Salvatore (antirez?) not
having to do this work for free. Indeed, VMWare may be spending a good chunk
of change paying for his services ( <http://antirez.com/post/vmware-the-new-
redis-home.html> ). I do not wish to suggest that he go uncompensated.

What I do wish to suggest is this:

VMWare: this dude you are paying to develop a widely-used and respected
project has (seemingly arbitrarily) turned down code submitted from other
practitioners in the field. He has suggested they fork the project (diluting
the quality of the Redis brand and potentially removing resources that could
improve mainline Redis). He has suggested that the project is too difficult to
make cross-platform; I'm sure that you folks might have a different opinion on
how important cross-platform support is.

Pay him more to make a better project (with help from people in the
community!). Or acknowledge that he is correct in his assessment that this is
somehow a Linux-only problem. Or do something else to help him figure out how
his goals align with the VMWare mission.

~~~
beagle3
> If I'm not mistaken, 4 actually very much does follow from the preceding
> points.

Then you should go back to logic school. Let me make it clearer for others
reading this, as yourself appears to be a lost cause:

(1) Microsoft develops web browser (2) rendering could theoretically be made
standard compliant with minor changes (3) people submit style sheets and
javascript files that, if included in a web page (or embedded into IE) would
achieve that functionality. (4) Users can reasonably expect Microsoft to do
that.

Wait, what?

Furthermore, your logic breaks in other places:

(5) ... there is no demand for it (from article: "I don't think Redis running
under win32 is a very important feature.").

How does "not important" imply "no demand"? Let me give you an example that
will make it clear:

"Apple just said that getting Win7 apps running on the iPad is not important".
You bet there's demand for that, and yet that does not make Salvatore's or
this (fictional, but realistic) Apple quote wrong in any way. "important",
unless otherwise qualified, is to the speaker.

(6) Users have been denied functioning code because of arbitrary decision by
guy.

Wrong. They could just build it from source. Less convenient? Well, it takes
just one person to package it and make it into an .msi.

Furthermore, the decision is not arbitrary -- you may disagree with the
reasoning, but he gave detailed reasoning.

You sir, are either an idiot or a masterful troll -- I would pick the first,
if only because it makes me feel better to think I haven't been trolled :)

~~~
tptacek
We shouldn't call people idiots, or, really, trolls. Berate the argument, not
the commenter.

~~~
beagle3
That's true. And I mostly follow this.

When the other person consistently ignores logic and invents their own facts
and reality, I occasionally adopt the Linus strategy; but I still take care to
address the argument itself.

Point well taken. HN is a better place thanks to people like yourself.

~~~
tptacek
Blah, I'm 100x worse than you are about calling people names, but for what
it's worth: if you write a similarly worded comment to me, I'll try my best to
thank you for it instead of getting bent out of shape. :)

