Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Simplicity of IRC

susam.net

Post reply on HN
Print view View original

181–190 of 250 posts

Re: Simplicity of IRC

#181

Post by akkartik »

ripe wrote: post #75
dan-robertson wrote: post #6

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…

Yes! I learned BASIC on the BBC Micro. You turned it on, and you got a BASIC interpreter. It was the most painless, most fun experience. Graphics, sound,, etc., were all available by reading the User Guide. I couldn't have afforded buying one, but my university had half a dozen. I wish kids today could get that.

This was my attempt at providing easy graphics to kids inspired by the BBC Micro: https://github.com/akkartik/mu/tree/main/shell

Here's a 6-minute demo: https://archive.org/details/akkartik-mu-2021-06-09

Requires Qemu, though. And no sound yet, unfortunately. I'd love contributions there or elsewhere.

Re: Simplicity of IRC

#182

Post by tarkin2 »

c0l0 wrote: post #176
tarkin2 wrote: post #174

Earlier quoted context omitted.

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 pref…

Thanks, I was inspired by your post and looked at irc servers. The main problem, vis-a-vis slack, was the channel history. There are modules but they have timestamp and limit problems. And irssi in gnu screen would only work while screen is running and would only work for those happy with the setup. ZNC, although sadly adding more complexity, seems to be the way to go.

Re: Simplicity of IRC

#183

Post by Nextgrid »

gavinray wrote: post #104
323 wrote: post #42

Earlier quoted context omitted.

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.

Do they make an exception for Mac, considering recent macOS no longer supports 32-bit binaries?

Re: Simplicity of IRC

#184

Post by zacmps »

c0l0 wrote: post #176
tarkin2 wrote: post #174

Earlier quoted context omitted.

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 pref…

ZNC has its own issues. We had a repeatable crash that happened every time a particular user connected (it took us a while to figure that out).

Re: Simplicity of IRC

#185

Post by 41b696ef1113 »

arbaal wrote: post #85
c0l0 wrote: post #13

Earlier quoted context omitted.

Maybe that wasn't possible/enabled for our particular deployment (that was in the IT dept. of a big European bank), as we had what I've been told was a strange bastardization of O365 and other MSFT services - a mix of on-prem and cloud services unlikely to be found elsewhere. At any rate, for the IRC server at the shop I was at previously, I had "webhook" support/a http(s)->irc gateway implemented on my own in much l…

Isn't your comment then very specifiy for that installation of yours? When you use MS Teams in a "normal" O365 environment, then every feature you described for IRC is possible with weebhooks and the cards API. Simple CURL based integration.

I will second with another anecdote at mega corporation - Teams is entirely locked down and any of the useful integration points are disabled.

Re: Simplicity of IRC

#186

Post by Blikkentrekker »

janc_ wrote: post #159
Blikkentrekker wrote: post #74

The simplicity also comes with problems, such as nickname registration in practice being implemented with bots that have administrative rights, which can lead to social engineering exploits and poor standardization of their interfaces, or the fact that the protocol does not seem to support sending an encoding so it relies on the gentleman's agreement that everyone use UTF-8, which works until that one user using lati…

You mean IRCv3? It’s not all ready/implemented yet, but some of it is already in daily use. https://ircv3.net/ For example a server can tell the client that it only accepts UTF-8: https://ircv3.net/specs/extensions/utf8-only

Well I am still sometimes seeing this user that is sending latin-1, confusing everyone else.

I also wish that nicknames would not be handled via the hack of bots, as this sysem allows one to take a nickname one does not own, at least for a short while, but simply no identify it and ignore that message, and thus impersonate another user.

Re: Simplicity of IRC

#187

Post by c0l0 »

zacmps wrote: post #184
c0l0 wrote: post #176

Earlier quoted context omitted.

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 pref…

ZNC has its own issues. We had a repeatable crash that happened every time a particular user connected (it took us a while to figure that out).

Sure, most software projects and products have their share of flaws and bugs :)

I do not claim ZNC or our whole IRC setup was perfect, but for me and many others, it did a very decent job of providing effective, no-frills, getting-things-done means of communicating, all while consuming little resources on both server and clients, and being simple, underestandable, and easy to hook other software into.

I really miss it, and personally dislike (especially the client UX of) most trendy/recent alternatives.

Re: Simplicity of IRC

#188

Post by 323 »

mdoms wrote: post #163
ryandrake wrote: post #133

Earlier quoted context omitted.

Reminds me of this visualization[1]. The amount of code it takes to simply draw a triangle in OpenGL 1.x, OpenGL 3+, and Vulcan The learning curve has been sacrificed. It's now a learning cliff for everything. We've used to have computers that make it simple to do simple things and hard to do complex things. Now, just so it can be slightly less hard to do complex things, we've made it hard to learn and do simple thin…

I have never written for Vulkan and have only done bits and pieces of OpenGL but this can't possibly be an honest representation can it?

Even conceptually using Vulkan is much more complicated.

In old GL it's basically glClear, glBegin, glVertex, glVertex, glVertex, glEnd and a bit of window setup.

In Vulkan you need to know what these things are: queues, command buffers, image/geometry buffers, memory locations (constant, uniform, varying), resources, bindings, shader programs, fences, swap chains, and how they all coordinate together.

And until they are all properly coordinated together, you'll just be staring at a black image or just get errors.

Re: Simplicity of IRC

#189

Post by laumars »

trixie_ wrote: post #173
laumars wrote: post #53

Earlier quoted context omitted.

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.

I cannot comment on the switching between WiFi and data aspect because I’ve not tried that myself (though it didn’t work on my MBP switching between Ethernet and WiFi) but everything else you’ve described is pretty standard features for video conferencing solutions these days.

I’d like Teams more if it just focused on the video conferencing side of things. It’s chat and Sharepoint integration just adds more frustration than anything.

Re: Simplicity of IRC

#190

Post by trixie_ »

laumars wrote: post #189
trixie_ wrote: post #173

Earlier quoted context omitted.

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.

I cannot comment on the switching between WiFi and data aspect because I’ve not tried that myself (though it didn’t work on my MBP switching between Ethernet and WiFi) but everything else you’ve described is pretty standard features for video conferencing solutions these days. I’d like Teams more if it just focused on the video conferencing side of things. It’s chat and Sharepoint integration just adds more frustrati…

Seamlessly going from a chat about a problem, to a video meeting, to screen sharing, to sharing files, and then continuing the conversation on mobile, to scheduling a teams meeting later in the week to follow up and fully integrated into outlook is what I’m talking about.
Post reply on HN