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

Simple Unix Chat

the-dam.org

Post reply on HN
Print view View original

61–70 of 175 posts

Re: Simple Unix Chat

#61

Post by benrutter »

000ooo000 wrote: post #30

As a feat, I like this. It's cool to see what can be achieved with composition. That said, I don't care much for the comparison to Slack etc. No engineer wants to be on the hook for a bunch of things cobbled together like this in production. How are you going to hire talent? How do you test the thing? Debug it? Logs? Analytics? This piece replicates (some of) the chat functionality of Slack et al but the chat functio…

This was my take as I read it too. It's definitely a great piece of engineering and I really enjoyed reading about it, but comparing it to Slack rather than just IRC feels disingenuous.

That said, I'd be really interested in what tools like Slack would look like if they aggressively pursued simplicity ahead of new features. Capitalism as a whole doesn't seem to encourage this kind of development, so there aren't many examples in the wild of enterprise software that is as simple as it could reasonably be. Nonetheless, it's an interesting thought experiment.

Re: Simple Unix Chat

#62

Post by linschn »

cornel_io wrote: post #24
spicybright wrote: post #8

In case you're passing over this because it sounds like click bait (it KIND OF is), this was actually a good read to me. It goes over a utility called "suc" (Simple Unix Chat) that implements server functionalities from Slack, Discord, etc. using a very small codebase. The novel part is it leverages existing unix tools and methodology instead of re-inventing them. - Auth is handled by SSH. - Channels are just a file…

Slack to most end users is the client, though. As well as the admin, user management UI, scalability, webhooks, etc, absolutely none of which is handled by "you can chat with other users in Linux if you all log into the box" which every *nix has had since before most readers here were born.

Indeed ! The question is whether all that is worth so many engineer-hours. I'm not advocating for all Slack channels to be replaced by suc, that would be silly. I'm just pointing out how costly it all is. There's got to be a middle ground that does not require hundreds of thousands of lines of code.

Re: Simple Unix Chat

#63

Post by linschn »

numpad0 wrote: 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 expensive is it to leave Slack ?

Sure, suc sucks, but we probably could converge on something less bloated and proprietary than Slack ?

Re: Simple Unix Chat

#64

Post by benrutter »

eyelidlessness wrote: post #10
kitchi wrote: post #7

Earlier quoted context omitted.

I had a similar thought. But it also struck me that "externalising the maximalism" by using a library like the unix ssh implementation is probably the best way to go about it, since it's a widely used well tested library that implements a complex use case. In scientific programming I'd say that's the same as using a library like GSL, BLAS or even numpy. The net impact on LoC in my project is minimal, even though it c…

> But it also struck me that "externalising the maximalism" by using a library like the unix ssh implementation Not saying this to be argumentative, only to emphasize the same conflicting dynamic I saw in the post: this is exactly the same rationale that people routinely lambast here about NPM and other sources of dependencies. It’s libraries and frameworks all the way down. I’m cool with that, I’m just not cool with…

It's interesting to think about where such a principle would land.

I think having five lines of code (well, it's more like 50 of so reading the article) with some key and reliable dependencies is better for maintainability than having no dependencies but a substantially larger code base. As you point out, there's definitely limits, and npm's left pad, is odd and is even packages are obvious example where the added dependency is less maintainable than implementing the code directly.

Re: Simple Unix Chat

#65

Post by linschn »

anonym29 wrote: post #6

I understand the blog post here is about suc, and it is acknowledged immediately and honestly that the headline is slightly misleading, but there's an important message here that ultimately has nothing to do with suc. Almost all modern software is bloated to hell. The idea that one would need 1.7 million LoC for a rich chat server is absurd. To paraphrase Bill Gates, I don't think I could "spend" that many lines of c…

I want to thank you sincerely for capturing the sentiment of the piece. This is exactly what I had in mind and I'm genuinely happy you were able to get that from the text :)

Re: Simple Unix Chat

#66

Post by linschn »

lolinder wrote: post #21
anonym29 wrote: post #6

I understand the blog post here is about suc, and it is acknowledged immediately and honestly that the headline is slightly misleading, but there's an important message here that ultimately has nothing to do with suc. Almost all modern software is bloated to hell. The idea that one would need 1.7 million LoC for a rich chat server is absurd. To paraphrase Bill Gates, I don't think I could "spend" that many lines of c…

FWIW, most of the TypeScript lines of code are in the E2E tests[0] and the webapp dir [1], which, as the name suggests, contains "the client code for the Mattermost web app". So we should really only be counting lines of Go code. [0] https://github.com/mattermost/mattermost/tree/master/e2e-tes... [1] https://github.com/mattermost/mattermost/tree/master/webapp

I'll edit the article accordingly, thanks for looking into it.

Re: Simple Unix Chat

#67

Post by linschn »

jesuspiece wrote: post #16
photonerd wrote: post #9

Earlier quoted context omitted.

While I agree in principle, a lot of the bloat is due to trying to have one codebase for a lot of different platforms. This is generally a good ideas as it increases the speed you can ship & reduces the size of the org. But there’s a big trade off: complexity & abstraction. The higher level your abstractions the worse it gets too. So it’s not without reason.

also to make it user friendly. I know we're on HN so we're all tech people but this is super nerdy stuff lol. This would never get mass adoption like tools like Slack have that work across multiple platforms, including mobile

Yeah, mobile is tough. Termux works, but not as a comfortable experience as whatsapp. I'll see what I can cook up.

Indeed, multiplatform is very very costly.

Re: Simple Unix Chat

#68

Post by linschn »

mappu wrote: post #14

Most current distros prevent you from making setuid bash scripts, on security grounds. But you can get most of the same effect with a specific sudoers entry.

I use a C wrapper that calls the shell script. Ugly, and I need to harden the script a bit more, but it works :)

https://gitlab.com/edouardklein/suc/-/blob/master/suc_wrappe...

Re: Simple Unix Chat

#69

Post by linschn »

kelvinjps wrote: post #44
kitchi wrote: post #7

Earlier quoted context omitted.

I had a similar thought. But it also struck me that "externalising the maximalism" by using a library like the unix ssh implementation is probably the best way to go about it, since it's a widely used well tested library that implements a complex use case. In scientific programming I'd say that's the same as using a library like GSL, BLAS or even numpy. The net impact on LoC in my project is minimal, even though it c…

I think that the main difference is that unix tools are intended to work which each other. Therefore needing less line of code. As opposed on other systems.

That was exactly part of the point I was trying to make with the article. The other, that I left unsaid but should probably add explicitly, is that Slack et al. run on a server with a kernel, but choose to ignore the access control capabilities of said kernel and instead chose to reimplement them. I think it is a shame, and more software should strive to be security agnostic instead of reimplementing access control for the umpteenth time.

Re: Simple Unix Chat

#70

Post by linschn »

ramses0 wrote: post #48
Gigachad wrote: post #5

How do I make a call with this?

cat /dev/audio | ...semi-unironically... (whoops, forgot the gzip/gunzip filters...)

I'm seriously considering trying something like this just to see if it works. TCP would kill it though (maybe?). But maybe UDP plus some clever ffmpeg invocation...
Post reply on HN