Live data from Hacker News

Simplicity of IRC

susam.net

101–110 of 250 posts

Re: Simplicity of IRC

#101
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…

Source code [0] is available on GitHub; looks like they wrote their own simple site generator. I've been thinking about something similar (maybe even simpler) for my blog too. [0]: https://github.com/susam/susam.net

Thank you for sharing the link to the source code. My simple site generator is based on my wife's project makesite.py[1]. In fact, I used her site generator for a few years. Later I reimplemented makesite.py in Common Lisp. As a result, it inherits the design, layout, minimalism, and simplicity of makesite.py.

[1] https://github.com/sunainapai/makesite/

Re: Simplicity of IRC

#102
post #87

I love IRC, unfortunately it doesn't work properly with smartphones because they have a "loose" connectivity (4G towers data etc). I'm not sure IRC apps can deal with this already. It would be nice to have some update to the IRC RFC. If it was well supported for smartphones, I'm still wondering if it would cause some bandwidth costs to servers. EDIT: I know about bouncers, but I would prefer to do without.

It works well for me by using screen and irssi on a server and then using mosh on the smartphone to connect there, as well as irssi-notifier for notifications. Has worked well around the work, including traveling in africa, from high speed trains in Europa and airplanes above the Atlantic. And before you say "but that needs a server". Yes it does. A little VM as a shell host that is cheaper be month than the cheapest nitro package on Discord. Not even one coffee per month. If you don't think it's worth to have control over your communication for that price, I can't help you.

Re: Simplicity of IRC

#103
I've finally migrated away from the last of my irc channels the last remaining people except for one holdout agreed it's time to move on. Things have been way better since the switch..I wouldn't go back, a new bar has been set

Re: Simplicity of IRC

#104
post #42
post #36

Earlier quoted context omitted.

However, today there is no VB-like experience for modern development regardless how much you’d be willing to pay for it.

Delphi still exists: > Build Native Apps 5x Faster With One Codebase. For Windows, Android, iOS, macOS, and Linux https://www.embarcadero.com/products/delphi And it's free if you don't make a lot of money of what you build.

And if you don't need/want to compile to x64 bit

Delphi Community Edition only allows x32 compilation

I downloaded it to try. It's not a huge limitation for most usecases I would imagine.

Re: Simplicity of IRC

#105
post #98
post #88

Earlier quoted context omitted.

That is, unless the enterprise has policies to abide by disallowing API calls, in which case you're stuck with the official client and vetted integrations. Same for mobile, the advantage vanishes once enterprise requires your (usually personal) phone to be surrendered to corp IT via MDM (which I sure as hell won't do). The whole value proposition of Slack and Teams for their customers is control.

Would IRC even work in that nameless enterprise?

IRC might be run by engineering there for themselves. 3rd party chat would got through procurement and be provided by IT for the whole company, and after the last SOC2 audit, they had to lock it down.

Re: Simplicity of IRC

#106
post #98
post #88

Earlier quoted context omitted.

That is, unless the enterprise has policies to abide by disallowing API calls, in which case you're stuck with the official client and vetted integrations. Same for mobile, the advantage vanishes once enterprise requires your (usually personal) phone to be surrendered to corp IT via MDM (which I sure as hell won't do). The whole value proposition of Slack and Teams for their customers is control.

Would IRC even work in that nameless enterprise?

Technically, yes. In real life, no.

I don't even blame such enterprises because most of the time it comes from regulations or outside policies that customers mandate, something like all enterprise data (and thus communication) has to be firmly under control of the enterprise with hard guarantees, otherwise you just don't get to work with those customers. So you get a locked down Slack/Teams, and the email+calendar system disallows any native app unless the device is MDM'd, and even that is only with first party clients such as the Gmail app or Outlook.

TBH I think most companies are trying to do their best there, but they're stuck with some kafkaesque liability system.

Re: Simplicity of IRC

#107
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…

I find Matrix a fine substitute for IRC. Very simple to write clients and bots for. And you get modern features IRC either lack or does not do well.

Re: Simplicity of IRC

#108

Earlier quoted context omitted.

100%, the fact that you can literally pipe some data in a command-line IRC client is 1000x more conducive to such tweaking than using custom APIs/SDKs long live the Unix model!

I don't see why you couldn't do the same in a Slack command-line program as well? Not hard to find simple examples of that. https://github.com/csabapalfi/slackcat

I think the op meant on the protocol level, not client. You can literally do `cat mycommands.txt > /dev/tcp/...`. IRC is pretty simple, I remember using telnet just for fun to connect (also the PING message replies are annoying to type yourself) and at one time, (ab)used an FXPable FTP server data port trickery in ASCII mode to send a message to a channel.

Due to its simplicity I could see its application as a falback for global communication downtime/outages (as we had with FB/Insta recently).

Re: Simplicity of IRC

#109

I've finally migrated away from the last of my irc channels the last remaining people except for one holdout agreed it's time to move on. Things have been way better since the switch..I wouldn't go back, a new bar has been set

Preferred chat notwithstanding, at least the holdout didn't go the xkcd route: https://xkcd.com/1782/

Re: Simplicity of IRC

#110
post #54

Earlier quoted context omitted.

I tend to agree. I have the same reservations with HTTP2 to a lesser degree. I won’t deny that the complexity added by HTTP2 will greatly improve speeds in certain cases, and this may very well be needed to keep the greater interwebs working at comfortable speeds moving forward, but a part of me is greatly saddened by losing the sheer simplicity that is HTTP1.1.

Are we going to lose the simplicity of HTTP/1.1? I think that would only happen when we get servers that support only HTTP/2, and I hope those will be limited to hobbyist use for a while yet.

gRPC servers, which are increasingly common and certainly not a hobbyist thing, are http/2 only.
Post reply on HN