Live data from Hacker News

Simple Unix Chat

the-dam.org

101–110 of 175 posts

Re: Simple Unix Chat

#101

It’s cute and fun if you’re the kind of person that enjoys terminal UI’s and can keep an encyclopedia worth of CLI tools and options in your head. I don’t enjoy Slack and the like due to the notification overload and FOMO burnout. The UI is a memory hog for what it does. But for the computer user that wasn’t born at Bell Labs with a keyboard in their hands, it’s pretty decent. If you can navigate gmail or a word doc…

I think part of the point the author was making is that rendering and interacting with the server can vary depending on the client you build. You could have a CLI client or a React client and build them with two completely different goals in mind. For example, monitoring and botting channels vs. end-user experience.

Re: Simple Unix Chat

#102
post #71
post #26

Earlier quoted context omitted.

In what way is its functionality "nearly the same as Slack"? Or are people these days just using Slack as a generic term for "channel-based chat" without acknowledging the long history of chat apps? (In which case I would argue it is much closer to the functionality of IRC, if still significantly short of it).

I agree that Slack is much more featureful, but I fail to see what critical piece of IRC functionality is missing ? If anything, you don't need a bouncer for chat history with suc, so it's more featureful than IRC. With that said, I seldom used IRC so this is a genuine question for people who used it and miss some features.

It's been years since I used/administered IRC, but I also think there are common misconceptions about what IRC actually is. At it's core, IRC is an incredibly basic tool, and most of the end-user features come from layering additional services on top of IRC, both at the client and server levels. These services can be pretty complex and cumbersome to manage, and in my opinion, never quite seem to solve the problem exactly. Persistent chat history is certainly the most glaring example.

At the risk of becoming a meme, it's similar to how practically nobody uses Linux alone; it's almost universally accompanied by something like GNU.

Re: Simple Unix Chat

#103
I’ve always been really intrigued by the idea of building things as simply as possible and leveraging as many existing tools as I can to do so. My problem is that most of my projects require a web frontend which would mean calling bash scripts from Go (or whatever language I implement the server in). This just FEELS wrong, but I can’t really articulate why. Am I wrong to feel that way or is there some good reason I’m not seeing to not wire up bash scripts like this?

Re: Simple Unix Chat

#104

I’ve always been really intrigued by the idea of building things as simply as possible and leveraging as many existing tools as I can to do so. My problem is that most of my projects require a web frontend which would mean calling bash scripts from Go (or whatever language I implement the server in). This just FEELS wrong, but I can’t really articulate why. Am I wrong to feel that way or is there some good reason I’m…

Unless you are writing very tight code (like for a real-time system, or something you know will be invoked millions or billions of times) then shipping > code golf. Bash away!

Re: Simple Unix Chat

#105

It’s cute and fun if you’re the kind of person that enjoys terminal UI’s and can keep an encyclopedia worth of CLI tools and options in your head. I don’t enjoy Slack and the like due to the notification overload and FOMO burnout. The UI is a memory hog for what it does. But for the computer user that wasn’t born at Bell Labs with a keyboard in their hands, it’s pretty decent. If you can navigate gmail or a word doc…

Of the three (Slack, Teams, Discord) I actually prefer Discord. Its the easiest to use, the fastest, etc. Too bad that any corporation of size uses Teams or Slack.

Re: Simple Unix Chat

#106
post #63
post #13

I think the intuition would be that if a determined "core" feature set of something is so easily and trivially reproduced, then it's not the core/source of its value. Which makes me wonder: Just how much of UI development had software engineering had consumed and automated since 1980s, or is it still in the realm of pure human art?

This is a very astute way to look at it. I'd say then that the value of Slack is to be user friendly, which suc definitely is not for muggles. But then more difficult questions arise: - Is the price of slack worth it, when the alternative is having more educated users that can do very basic command line calls ? - Same question, but taking into account that Slack captures your data and won't give it back to you ? How…

Is suc scaleable? I didn’t see any discussion of managing conversations across a cluster of ssh-capable hosts and you’re not going to support more than a few thousand with a single ssh server.

Re: Simple Unix Chat

#108

>"Half a million lines of Go, and again half a million lines of TypeScript. Just for the server ! Let’s compare with suc: suc can implement Mattermost’s core features with 0.005% of the code . This is madness !" Madness indeed! But that is also why this is such an awesome article! Upvoted and favorited!

Your enthusiasm made me smile :)

Re: Simple Unix Chat

#109

$ rain | wall #.. my favourite thing to do to my colleagues during the end of coding marathons we'd find ourselves in, during the 80's ... on machines that weren't always fortified against the rain .. ;){

I couldn't make talk or wall work on a modern linux system. That's a shame.

Re: Simple Unix Chat

#110
post #63

Earlier quoted context omitted.

This is a very astute way to look at it. I'd say then that the value of Slack is to be user friendly, which suc definitely is not for muggles. But then more difficult questions arise: - Is the price of slack worth it, when the alternative is having more educated users that can do very basic command line calls ? - Same question, but taking into account that Slack captures your data and won't give it back to you ? How…

Is suc scaleable? I didn’t see any discussion of managing conversations across a cluster of ssh-capable hosts and you’re not going to support more than a few thousand with a single ssh server.

This is something I would like to explore. If I had to guess now, I would think that the management of many open handles on a single file by the kernel is going to be more limiting than ssh.

But I'd also wager we can go quite far with a single cheap VPS. A few thousands user does not seem impossible at all.

Post reply on HN