Hacker News Reader

Comment by sdf43543t345 | Hacker News Reader

IRC had uptime in the scale of decades. Why are our 2018 solutions so fragile?

Eh, IRC networks split and individual servers went down all the time. But yes, there rarely was a complete EFNet outage even if sometimes there were 2 versions of the same channel going at once.

That being said although I like some slacks fancy features I do wish a distributed alternative could catch on.

Native emoji support, aesthetically pleasing front-ends, and clear product direction are some of the main positives I see, even if the combination of php on the backend and electron on the frontend aren't the most sophisticated technical components in history.

I prefer decentralized and open things, but a cohesive vision can sometimes provide a better user experience across a more restricted set of functionality than an army of hackers, each solving their own problems.

Offline messaging, mobile clients, push notifications, history, search, rich text formatting, message editing, file transfer, etc etc etc

..., inline images, display names, deleting messages, editing messages, reactions, avatars, multi-user private messages, etc etc etc

Have you tried IRCCloud? Their web based front-end is as nice as Slack's but it still works with decentralized IRC servers. They also manage the client's state (unread messages) better than regular IRC bouncers.

Emoji seem to work just fine on IRC nowadays, what do you mean by "native" support? The shortcodes? The fact that there's official clients you can entirely rely on supporting it?

Native emoji support, pretty front-ends, and clear product direction are possibilities on-top of IRC (or XMPP) since their absence isn't a core part of IRC (or XMPP) -- it's just not a good way to make a profit it if you don't lock down the network and act as the gatekeeper of the interface. Slack's API is fairly open though and it's not a huge hurdle to interact with it. I built an IRC<->Slack gateway that bridges the differences fairly well ( https://slack.tcl-lang.org/ , you know, if Slack were working).

IRC netsplits quite a bit, breaking ongoing conversations until it’s recovered, to be fair.

Small ircds that you would run for a single team don't split because it's a single server.

Large networks can have the servers go up and down, and it's still not a big deal because of redundancy. DNS round-robin entries mean you don't even have to know the other servers on the network.

In 2018 netsplits caused by down links are fairly rare. If you wait six months you might see one.

And if you run a small single-point ircd, at some point, the server or it’s internet connection will fail, and you’re in the same position as when Slack fails.

There’s nothing that gets around technical failure. Either you have a single server that’s going to die at some point due to sheer entropy, or you have a somewhat complex distributed system with the tradeoffs you desire that might fail anyway.

The downtime would be for a network connection failure and not because your 'fearless' NoSQL container didn't work as expected. If a transient networking problem like this is a big deal for you, you can easily add either more nodes or move the node to a place with more reliable networking.

Or because the IRCd written in 90s-style C++ by some people who honestly don’t know what they’re doing segfaulted, or because you accidentally K-lined 0.0.0.0/32, or because you accidentally filled up the disk with logs because the server’s maintainer was fired and nobody remembers how the system works, or the latest system update borked something, or a failure to update the system allowed someone to attack your network, or the really hacky mechanism you use to enable auth against Active Directory broke or allowed a disabled user to log in, or...

There’s a lot more that can go wrong than that a database falls over. In my experience, IRC servers fall over all the time - it’s just that nobody really cares because their clients just connect to the next server in the list and people resume their conversations a minute later after figuring out what messages actually reached their destination.

Paying IRCCloud to manage an IRC server for you is a reasonable option, but I wouldn’t do it because I think it’s going to be more available, but because I like IRC and believe it provides the functionality I need.

> Or because the IRCd written in 90s-style C++ by some people who honestly don’t know what they’re doing segfaulted,

Don't use a 20 year old ircd then. Use something like ratbox or InspIRCd.

> or because you accidentally K-lined 0.0.0.0/32 or because you accidentally filled up the disk with logs because the server’s maintainer was fired and nobody remembers how the system works, or the latest system update borked something

Don't let 14 year olds run your server.

https://en.wikipedia.org/wiki/Netsplit

Anybody knows why the netsplit was written

  *.net *.split

Why those stars and dots ?

I believe it's an effort to show a netsplit in the traditional form (server1, server2) without placing blame on a particular server.

Back when I IRCd regularly (and perhaps this is still the case today), certain servers would get a reputation for splitting more than others, and I think this network (and/or its ircd) decided to mask it without breaking the general format.

It's to avoid showing the server names to the public on some IRC networks for various reasons including security through (some) obscurity.

I recall net splits happening all the time so I'm not sure that ircs uptime was a practical real world "decades".

I mean, most IRC networks at least have netsplits from time to time.

The power of centralization! If I can't have it, you can't either! I wouldn't say it's fragile, though. Just like normal IT work, people only pay attention when it isn't working.

Really? It maybe up, but Netsplits occur all the time.

sdf43543t345 has quit the server (Net split)

Because they're single-source, single-point-of-failure (in the case of Slack), and very very very complex.

Major IRC networks had uptime on the scale of minutes, in my experience…

writing entire stacks in javascript, probably

Given how much more robust Slack is than IRC as far as features go, it's probably not fragile. The closer a piece of software is to the network layer, the more stable it tends to be, just due to the internet's robustness.

Reply on news.ycombinator.com