Simple Unix Chat
the-dam.org
Simple Unix Chat
1–10 of 175 posts
Re: Simple Unix Chat
#2Very cool! I love seeing things like this put together using just basic unix tooling. I dont know if I'd call it a slack clone though, but cool nonetheless.
Re: Simple Unix Chat
#3Functionally, this is nearly the same as slack, but it's missing the aggressive venture capital funding and marketing team...
Re: Simple Unix Chat
#4> suc does all that by leveraging SSH, UNIX’s access control API, and UNIX’s text-based modularity.
On any fair metric, this should inflate the volume of code metric for any project (whether leveraging those APIs directly or not). It would still favor this implementation on that front, and there are still other merits to the approach besides code volume. But something does irk me about touting supposed minimalism which externalizes almost all of its maximalism. Sure, the dependencies are probably there and sure, it’s good to use the platform. But it’s not a reasonable claim that “five lines” can recreate any portion of any moderately complex software. Otherwise we’d have “SSH in five lines of bash” and so on.
Re: Simple Unix Chat
#5How do I make a call with this?
Re: Simple Unix Chat
#6I 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 code on a rich chat server if I tried.
Kudos not for simply calling attention to the problem, not for simply proposing an alternative, but for reminding people that the wheel need not be reinvented - cleverly implementing existing systems & subsystems to utilize their properties (e.g. ssh for authentication and encryption) in a manner that meets the intentions of those properties but not the originally imagined purpose of the system or subsystem is as good an example of the hacker ethos as any, and the software world would benefit immensely to draw from this concept. Lower costs, shorter development timeframes, and less engineering hours wasted rewriting functionally identical code is good for the developer, good for the company doing the developing, good for the end user, and ultimately good for humanity.
I wish to see a lot more of this kind of creative destruction and will try to implement such clever techniques in future projects myself.
Re: Simple Unix Chat
#7> suc does all that by leveraging SSH, UNIX’s access control API, and UNIX’s text-based modularity. On any fair metric, this should inflate the volume of code metric for any project (whether leveraging those APIs directly or not). It would still favor this implementation on that front, and there are still other merits to the approach besides code volume. But something does irk me about touting supposed minimalism whi…
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 could potentially be calling thousands of lines of code. The point is that from a maintenance perspective I only need to maintain 5 or 10 lines, and if I find a bug in there I can file a bug report upstream, rather than maintain the complex details of the implementation.
The title is being a bit smart-ass for clicks and the author admits as much right at the top. But beyond that it's pretty great that they implementated a fairly basic version of slack with standard unix tools in a straightforward way.
Re: Simple Unix Chat
#8In 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 and admin/mod controls are handled by user groups and file permissions.
- Support for rich text, file uploads, etc. aren't a concern as you just write whatever data you want to the channels and let the client interpret it.
- Bots are very easy as you just pipe to/from the channel files.
You're not going to be making a perfect slack clone with the 5 lines that write messages to the channels from the article, but I'm pretty impressed how far you can with really simple unix tools.
Re: Simple Unix Chat
#9I 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…
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.
Re: Simple Unix Chat
#10> suc does all that by leveraging SSH, UNIX’s access control API, and UNIX’s text-based modularity. On any fair metric, this should inflate the volume of code metric for any project (whether leveraging those APIs directly or not). It would still favor this implementation on that front, and there are still other merits to the approach besides code volume. But something does irk me about touting supposed minimalism whi…
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 picking and choosing when it’s cool without any particular principle.