Live data from Hacker News

Simplicity of IRC

susam.net

171–180 of 250 posts

Re: Simplicity of IRC

#171
post #158
post #149

Earlier quoted context omitted.

Welcome to enterprise, where breaking things is a feature so commonly used Microsoft has documentation for it [1] and things are often deployed by people whose sole concern is "minimize attack surfaces". Our Teams installation not only disables API calls (official Teams client only), chat sessions are deleted if no one posts to them meaning most chat history is lost every weekend. [1] https://docs.microsoft.com/en-us…

What a perfect way to describe the situation. Imagine an enterprise disallowing all VCS service providers -- whether hosted on-prem or cloud -- because they use SSH instead of HTTP.

You think you're joking but I've lived through exactly that. Reason: SSH cannot be examined by a HTTP proxy. The moment we raised that HTTP CONNECT is a TCP passthrough thus equivalent we got to install a bespoke root certificate on our machines for the proxy to MITM every single connection.

Re: Simplicity of IRC

#172
post #20

It’s a real shame how difficult programming is. I don’t mean that it is difficult to write difficult things, but that it is difficult to write simple things. Once upon a time, one could download visual studio, click about to make a new project in (e.g.) Visual Basic, draw a gui in the gui editor, and click the run button. One could then start adding simple functionality (e.g. working through a book). Or even longer a…

> Once upon a time, one could download visual studio, click about to make a new project in (e.g.) Visual Basic, draw a gui in the gui editor, and click the run button The world that lived behind that experience - COM & Active X Controls - was extremely complex. If you needed to build a new active x control for your app, god save you. It's been said a million times, but in programming there is always complexity. Somet…

>If you needed to build a new active x control for your app, god save you.

regsvr32 coolcontrol.ocx

Re: Simplicity of IRC

#173
post #53
post #16

Earlier quoted context omitted.

The integrations are a neat trick, but often end up spamming a channel where people are trying to communicate. Teams seamlessly works across platforms, and mobile with video chat, files, outlook integration, and screen sharing. Maybe IRC could of been that, but it never happened.

Teams is by far and away the worst UI of any chat system I’ve used. I get why it’s designed the way it is, it’s trying to be Sharepoint, Slack, Zoom and Outlook. And as a result it does every single one of them worse. Sometimes integration is better left as event handlers rather than trying to make IRC behave like a Wiki.

Yea, but it works cross platform and on mobile. With the ability to carry voice connections from one to the other. Or even switch from wifi to mobile data without dropping. Even view people sharing their screen from mobile. For large teams and businesses I haven’t used anything better yet and we’ve gone through a lot over the years. Also Teams has met some strict Infosec reqs we need for mobile.

Re: Simplicity of IRC

#174
post #10

A number of moons ago, I switched from a company that used IRC for its internal, real-time, ephemeral communication needs to an enterprise shop that used Microsoft Teams to do that (and of course other communication stuff, as the boundaries for what was better kept in Sharepoint, Confluence, Email/Exchange, the legacy Wiki, and/or Teams were never quite clear :)) there. In the old shop, we eventually had all kinds of…

With your IRC system, how did you deal with channel history, i.e. seeing messages that were delivered to the channel while the user wasn't there, something that slack and teams does well?

Re: Simplicity of IRC

#175
post #10

A number of moons ago, I switched from a company that used IRC for its internal, real-time, ephemeral communication needs to an enterprise shop that used Microsoft Teams to do that (and of course other communication stuff, as the boundaries for what was better kept in Sharepoint, Confluence, Email/Exchange, the legacy Wiki, and/or Teams were never quite clear :)) there. In the old shop, we eventually had all kinds of…

With your IRC system, how did you deal with channel history, i.e. seeing messages that were delivered to the channel while the user wasn't there, something that slack and teams does well?

I'm not the OP, but the usual method is that everyone runs an irc client in a screen on a server that they SSH into from their workstation.

Re: Simplicity of IRC

#176
post #10

A number of moons ago, I switched from a company that used IRC for its internal, real-time, ephemeral communication needs to an enterprise shop that used Microsoft Teams to do that (and of course other communication stuff, as the boundaries for what was better kept in Sharepoint, Confluence, Email/Exchange, the legacy Wiki, and/or Teams were never quite clear :)) there. In the old shop, we eventually had all kinds of…

With your IRC system, how did you deal with channel history, i.e. seeing messages that were delivered to the channel while the user wasn't there, something that slack and teams does well?

We had an internal instance of ZNC for human users to connect their clients to (at their option - but that was the documented and preferred way of getting onto the IRC network). Creating ZNC user profiles was part of the semi-automated onboarding/setup procedure, whilst ZNC authentication was done against the dovecot IMAP/SASL server we had for email. More casual IRC users in the company (marketing etc.) usually preferred to use an intranet-hosted web application (The Lounge) to access it from their browser, while most IT people had native clients of their choice set up (hexchat, irssi, etc.). Worked well.

Re: Simplicity of IRC

#177
post #72

Earlier quoted context omitted.

> Windows comes with PowerShell (...) It might be just me, but PowerShell feels outright developer-hostile even when compared to Bash. Perhaps it's their approach to rely primarily on .NET stuff which makes things so arcane, but when given the option it's far simpler and better to go with, say, python than PowerShell.

I couldn't disagree more, I think bash is a horrifically bad programming language. Honestly I'm incredibly surprised anyone could compare PowerShell and bash and think that PowerShell is the arcane one.

PowerShell is the worst of bash and perl combined. It's like Microsoft took a look at each of those, "We can do that!" and implemented them.... worse.

Re: Simplicity of IRC

#178

I used IRC for gaming around 2004 - fond memories! I recently tried Discord to find programming communities but I just don't get it. When you join a server you are automatically subscribed to all the channels. And apparently you can't leave them, you can only 'silence' them by manually doing that for each channel. After a few days I just gave up as I could not keep up with all the notifications.

If you think about it like this, it makes more sense:

A server is to IRC what Discord is in its entirety

A channel is to IRC what a server is to Discord

If IRC let you subsection a channel, those would be channels to Discord

And instead of obnoxious netsplits, you get annoyed with popups to buy Nitro or whatever other crap whenever you log in

Re: Simplicity of IRC

#179
post #30

As an aside, can I just say how refreshing this website is? It's 100% content, just text. Now view the html source, and be amazed. I daresay the author actually wrote the html by hand. I suppose it could be a very conservative and conscientious site generator that even respects line length, but I'd be surprised. Short css file for minimal style tweaks, and readable markup. Fitting that the article is about simplicity…

Unfortunately, the inline code is dark blue, unreadable in dark mode.

Re: Simplicity of IRC

#180

Earlier quoted context omitted.

It did happen, though. Just not in the same way. When it gets to the point where notifications are too spammy, it's very very easy to direct things to use a different channel and it works at huge scale. Anyone who uses IRC more than casually via some web portal is capable of being in more than one channel at a time. Google SRE still uses IRC internally specifically because it always just works and does what people ne…

I find that the "fat" clients encourage bad behavior that IRC used to allow people to handle independently. Examples: * bot spam that I can't /ignore * "inviting" people to channels tht you can't opt out of (invite is slack terms is yank. there is not option to say no) * inline sharing of screenshots of article snippets that support an argument but not sharing links to the source material * so... many... channels...

> so... many... channels...

To compound the problem of many channels the UI uses an insipid three column layout. I like to arrange chat windows, tail -f terminal windows, and other monitoring things in a "dashboard" layout in a workspace. That way it can update in the background and if I am curious about the state of something I can decide to context switch and bring up that workspace to get an update. I can then deal with an issue or go back to the task at hand.

Slack and HipChat and all the other Electron-based attention siphons do not let me arrange their UI in a way that works for me. I hate notifications with the heat of a thousand suns and turn just about all of them off on all my devices. Slack et all hide the state of all but one channel by default and want to use notifications or stupid icons to show there's unread activity. It's the worst UI on the dumbest system but animated emojis!

Post reply on HN