Earlier quoted context omitted.
Again, your definition of popularity is different than mine, but either way my post still refutes his point about the declining userbase. > No, what I meant was, people no longer think of IRC as the tool to use to talk about projects and communities. They used to. That was its primary use case. That use case is shrinking, so IRC is becoming less popular. There's plenty of other avenues to use these days, so the numbe…
Try "IRC's mindshare is declining". rather than "IRC's popularity is declining".
Please don't use Slack for FOSS projects
461–470 of 499 posts
Re: Please don't use Slack for FOSS projects
#462Some open source self-hosted alternatives to Slack: * Rocket.Chat ( https://rocket.chat/ ) * Zulip ( https://zulip.org/ ) * Mattermost ( http://www.mattermost.org/ ) * Let's Chat ( http://sdelements.github.io/lets-chat/ ) Oh, and by the way, you could have your own Rocket.Chat instance running in Sandstorm in about 30 seconds: https://sandstorm.io/apps Update. And I would love to see a modern federated chat protocol…
Not sure why I would want to self host what is effectively a phone system. I have actual products to build. We could ease time self hosting source control as well -- to what end? I have members of the team spending time (and thus money) setting up something that pleases people philosophically but really adds zero value -- in fact, it actually costs money (through very expensive developer time.) I don't get the point…
That's an interesting parallel. I suppose it would technically be possible for a company to out-source their internal phone system to an external third-party using VOIP. But I've never seen it done and I don't know how I would persuade a CTO that it's a good idea to make internal communication reliant on the Internet.
Yet companies are falling over themselves to out-source internal IM... why?
Re: Please don't use Slack for FOSS projects
#463Earlier quoted context omitted.
I can do this until I'm rate limited.
I am terribly sorry I missed your request. I've been busy tending to my daughter and hastily dashing out some code I need for a teaching opportunity next week. I can see it caused you enough distress to post twice. Let me be straightforward with you, since you seem to be the sort that will not appreciate the standard cultural niceties. So perhaps maybe you just did a poor job to express your specific point as you tri…
My last two posts were specifically referring to the people who were downmodding me without posting any specifics. Unless HN hands out additional powers, which I have not been granted, you cannot downmod my responses to you. I did not mean to rush you (nor were my two parent posts in any way directed at you).
I will read your post now.
Edit: And likely post edit this post with responses.
>I can see it caused you enough distress to post twice.
I hope I was clear before, but I feel the need to state it clearly: you have not distressed me.
------------
Ok, many points are not relevant, but I'll respond.
>Let me be straightforward with you, since you seem to be the sort that will not appreciate the standard cultural niceties.
Thank you.
>So perhaps maybe you just did a poor job to express your specific point as you tripped over yourself to demonstrate to everyone you have read a bit of philosophy and logic.
I am waiting for the Straw Man.
> But it certainly would be reasonable that you entered a conversation without invitation responding to
No invitation required here.
>> That the reasoning is fallacious doesn't make the conclusion incorrect.
This actually depends on the conclusion. It depends on how all the words are defined, but basically, people come to non-real conclusions all the time.
>With:
>> However, if you study the truth table a bit longer, you will realize that you should stop reading any text which contains fallacious or self-contradictory logic.
>Implying that if you could construe any single statement in my post as lacking in robustness from a logical perspective, then you should simply ignore the entire thing.
My response was not directed at you. No, seriously. Go check the post history.
Also, that is basically the implication. And it's basically true. It's pretty much what you should do. Of course, there are many reasons not too: historical, curiosity, "maybe I read it wrong", etc. However, according the the rule of logic: there is no reason to consider fallacious logic in regards to any particular conclusion.
>This is regardless of the author's intent that this actually be a real point, or perhaps just a literary device or joke. One might actually read the whole post first, notice there is some technical substance, and come to a different conclusion before posting.
Fallacies should be called out as soon as they are detected. Consider the alternative: you are operating on fallacious logic. Good luck!
>This impression is further reinforced by your frustration over rate limiting as you implied that my response,
Again, my apologies for the confusion, but those frustrations were not directed at you, nor were/are they about you. You seem like a mostly pleasant person. (seriously)
>specifically saying that I didn't actually present my tautology as anything but a cute literary device to open what I considered to be a rather dry if somewhat acidic post.
And, yes. The Straw Man has not been presented (in my ~20min analysis).
>You said,
>> I've been rate-limited, so any fallacious (or non) arguments posted in response will need to wait a while for a proper response (some have already been typed up).
>Which from my perspective certainly looks like you were ready to fire off a post explaining to me with as many latin words as possible aimed at trying to prove exactly that.
The response I gave you is what I wrote up immediately before receiving the rate limit notice. I just kept the tab open and tried to post it every so often. I may have edited slightly after the first post attempt. I'd go read my response, then read the post the response was for, then come back here and read the above excerpt from your post.
>Perhaps, in the future, you may want to consider efficacy first and strict correctness secondly when discussing things in a casual forum with the (entirely barbaric, I agree) feature of "downvoting."
Please consider in any future encounters with me that I have already considered such concerns. Efficacy without correctness is madness. I cannot guarantee that I have considered all concerns, however.
>Or perhaps just not entering conversations you don't have anything substantial to add to.
I'm not not sure what this means. I don't consider posting a response on HN to be "entering conversations". It's some text in a tree, people can read it or not.
>You might feel some irritation at this, because it can seem like an anti-intellectual stance. Sadly, you're existing in a community that has to deal with many people perpetually misusing terms like "ad hominem" and "genetic fallacy" and "truth table" in the worst way, to the point where it's a cognitive shortcut to simply pass it by or perhaps even express this cultural signal via downvotes. I don't like it very much either, but cultural norms are not something we rationally argue with but instead can only hope to influence gradually.
I just try to point out the flaws as I see them. I'm not sure anyone else can do better.
Re: Please don't use Slack for FOSS projects
#464Earlier quoted context omitted.
This is like saying Apple products are popular because Apple has a great marketing team, as opposed to because said products are genuinely easier to use (they "just work") than their alternatives.
> (they "just work") Please don't say that Apple products "just work". We've got an office full of them.
I'd rather have "easier to debug when it doesn't work" than "just works, most of the times"
Re: Please don't use Slack for FOSS projects
#465To add to this, don't use Gitter for FOSS projects either. I've been seeing lots of projects abandon IRC for Gitter.
Re: Please don't use Slack for FOSS projects
#466>That the reasoning is fallacious doesn't make the conclusion incorrect. This is trivially true by the [material implication, modus ponens, modus tollens, other name, etc] truth table. However, if you study the truth table a bit longer, you will realize that you should stop reading any text which contains fallacious or self-contradictory logic. While the conclusion may be "correct", it is correct despite all of the o…
Re: Please don't use Slack for FOSS projects
#467tell them tater sent you
Re: Please don't use Slack for FOSS projects
#468Earlier quoted context omitted.
I am terribly sorry I missed your request. I've been busy tending to my daughter and hastily dashing out some code I need for a teaching opportunity next week. I can see it caused you enough distress to post twice. Let me be straightforward with you, since you seem to be the sort that will not appreciate the standard cultural niceties. So perhaps maybe you just did a poor job to express your specific point as you tri…
Sorry, HN doesn't provide the clearest interface for communication. My last two posts were specifically referring to the people who were downmodding me without posting any specifics. Unless HN hands out additional powers, which I have not been granted, you cannot downmod my responses to you. I did not mean to rush you (nor were my two parent posts in any way directed at you). I will read your post now. Edit: And like…
However, since I could not possibly write my post knowing you'd be reading, the social burden clear falls on you.
Please consider that.
> I just try to point out the flaws as I see them. I'm not sure anyone else can do better.
I hope this has value for you. It certainly has absolutely none for me.
Re: Please don't use Slack for FOSS projects
#469Earlier quoted context omitted.
There are many issues that prevent us from easily serving your use-case, unfortunately. I'm not completely sure about the details around this specific case, but historically we've had to restrict connections from similar software that makes N:N connections (or even N:M connections) to our network due to our connection limit rules quickly becoming unmanageable. We've recently implemented new software that should make…
Everything you've said in these past few comments basically boils down to: "Your use case would basically break EsperNet (but it's because of our implementation! We have a lot of issues with our implementation but they're not because IRC can't handle it!)." If the protocol's limitations mean that their use case is not viable due to the strain it places on the administrative side, it's still a limitation.
It certainly is a limitation, but any kind of service needs DDOS mitigation.
Re: Please don't use Slack for FOSS projects
#470Earlier quoted context omitted.
Mostly correct, but one nit to pick: IRC is not 7-bit; you can actually transmit unicode messages on every IRC network I've ever seen. It's also not usually unicode-aware, though, so if you send a message too long, it might get truncated halfway through a codepoint. Many IRC networks prohibit non-ASCII channel names and nicknames to prevent impersonation (e.g. with zero-width spaces). The rest of what you've said is…
IRC messages have CRLF message delimiters (and ASCII space field delimiters) and no quoting mechanism in the protocol. They're delivered over a long-lived synchronized TCP stream. Does it just happen that no 8-bit sequence people normally want to send on IRC ever manages to collide with 0D:0Ah? I haven't seen unicode messages on IRC channels, but I don't spend much time on IRC anymore, and so this is interesting new…
This is not possible on a technical level, having nothing to do with IRC itself, but instead written into the encoding design of UTF8.
First of all "7 bit" physical communication never really existed in the age of TCP - the protocol has always moved 8 bits at a time around. The "7 bit" era refers to nobody actually agreeing what codepoints within x80 ~ xFF actually mean. This is even partially true today - not everything has agreed on speaking UTF8 (hi Win32 APIs).
On the actual point of why neither 0x0D nor 0x0A will ever "manage to collide".
In a single-byte encoding (called codepages, https://en.wikipedia.org/wiki/Code_page#Noteworthy_code_page...) 0x0D always means just that, as pretty much all ASCII-derived codepages do... well, respect ASCII ( note - this does not touch on the horror of EBCDIC, which is alive and well today (2015) too ).
In the case of UTF8 any continuation byte can only carry values in the range of \x80 ~ \xBF, and any leading byte can carry values in the range \xC0 ~ \xF7. So no matter how you slice and dice things, the resulting UTF8 will have every ASCII character meaning itself (this includex \x0D and \x0A ), and the only ambiguity when mistakenly treated as any single-byte encoding would be in the "what do we do with the upper 7bit range" part ( \x80 ~ \xFF ). More info here: https://en.wikipedia.org/wiki/UTF-8#Description
True, other multibyte encodings are not so convenient: for example \N{MALAYALAM LETTER UU} ( http://graphemica.com/%E0%B4%8A ) looks really bad CRLF-wise in both UTF16/UCS2 an UTF32.
But this is why UTF8 "won" for all intents and purposes. And this is also why "escaping" is not necessary under virtually any modern environment, so IRC lacking any such mechanism is not really relevant.
( No opinion worth sharing on the rest of the article/discussion ;)