13 ms·

Simple Unix Chat

403 points by thm 3y ago

zzo38computer 3y ago
UNIX shell is good like that, that you can combine thing in shell scripts and command-line you can make such a combined program, if you are using programs that are designed to support that (unfortunately, too many modern programs don't, although some do). However, is there a race condition with writing to the files? Since it is append mode, I would expect that would prevent other processes overwriting the file, although would it prevent other processes writing in the middle of a line if it gets interrupted? Actually, I don't know. I had made a simple two user chat system with logging using ts, tee, and nc; using a shell script with only a single line of code. This produces two log files, one for sending and one for receiving; however, I can then use cat and sort to interleave the logs into a single log file.
pfych 3y ago
Very 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.
londons_explore 3y ago
Functionally, this is nearly the same as slack, but it's missing the aggressive venture capital funding and marketing team...
- peeters 3y ago
  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).
  - esafak 3y ago
    I was pitching a related concept to a young investor lately, and she had not heard of IRC. If you stick around long enough, all that is old is new again. If you can profit from this, it's great. If you can't, it is a source of frustration.
  - raincole 3y ago
    In the way a pen and a very long tape is "same functionaltiy as a modern CPU".
  - linschn 3y ago
    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.
    - BenLloydPearson 3y ago
      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.
    - progval 3y ago
      You don't need a bouncer for chat history when connecting to (the few) servers implementing https://ircv3.net/specs/extensions/chathistory https://ircv3.net/specs/extensions/chathistory
eyelidlessness 3y ago
> 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.
- kitchi 3y ago
  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.
  - eyelidlessness 3y ago
    > 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.
Gigachad 3y ago
How do I make a call with this?
- eur0pa 3y ago
  Use your phone
  - esafak 3y ago
    I suppose I should send an email instead of using suc then?
- ramses0 3y ago
  cat /dev/audio | <( mkfifo && netcat ) ...semi-unironically... (whoops, forgot the gzip/gunzip filters...)
  - linschn 3y ago
    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...
    - rvense 3y ago
      I think the main issue would be the buffering existing tools are likely to assume. You don't need more than a few hundred ms of latency for a phone call to start feeling really weird.
    - shrubble 3y ago
      If you went with the heavier-weight use of Asterisk, you could have softphones authenticated to Asterisk, but, no inbound calls from the softphones would be accepted. Only if 1 user sought to call another would Asterisk "dial" each softphone; which might be sufficient in terms of security (you would have to have a working SSH account to be called).
    - ramses0 3y ago
anonym29 3y ago
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 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.
- photonerd 3y ago
  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.
  - jesuspiece 3y ago
    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
    - linschn 3y ago
      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.
spicybright 3y ago
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 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.
- cornel_io 3y ago
  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.
  - linschn 3y ago
    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.
- dclowd9901 3y ago
  Big emphasis on “kind of”. “Here’s how to make $2 million dollars over night” _reads article_: “have $4 million in the bank…”
  - cassepipe 3y ago
    I laughed reading your comparison but I don't agree. I clicked waiting for a shallow trick and found that there was indeed a trick, but not a shallow one at all This ability to bring complex capabilities to a chat system by leveraging so much of its ecosystem is truly amazing. Definitely worth the hn front page. And you only need basic shell literacy in order to use it, little more to understand it
wfme 3y ago
This is very reminiscent of the initial hn response to DropBox [0]. This is like saying that you can build a Tesla clone by attaching 3 pieces of wood together along with 4 wheels. Although it is technically cool, it misses practically all of what makes Slack so popular - UX. [0]: https://news.ycombinator.com/item?id=8863 https://news.ycombinator.com/item?id=8863
- devmor 3y ago
  >it misses practically all of what makes Slack so popular - UX I strongly disagree. Slack has nearly the same UX as every chat platform of the past 2-3 decades. It's a slightly change over AOL Instant Messenger. There's also a large amount of very similar software or straight-up slack clones that are not very popular at all. I would say what makes Slack so popular is how easy it is to set up and get running, both as a service and for every user, combined with the availability of easy integrations/plugins.
  - thayne 3y ago
    > I would say what makes Slack so popular is how easy it is to set up and get running, both as a service and for every user, combined with the availability of easy integrations/plugins That is part of the User eXperience. I.e. UX.
  - maxcoding 3y ago
    What you are describing is quite literally the UX, the user experience, and Slack overall has quite a good one. Although several of the newer features are somewhat lacking in that regard, like the threads feature.
  - deleted 3y ago
    [deleted]
  - onetom 3y ago
    there are a bunch of features in slack beyond the core chat stuff, like: 1. being connected to multiple communities and switching between them instantly this can be of course simply replaced by connecting to different servers in a tabbed terminal and use the terminal's built-in cmd-1/2/... shortcut, which happens to be the same as in slack. 2. meta data about others, like their timezone or how to pronounce their name is quite important for distributed team work this can be approximated by a world readable file on the chat server in every user's home, like .plan or motd files (https://github.com/ESWAT/john-carmack-plan-archive https://github.com/ESWAT/john-carmack-plan-archive) 3. automatic idleness detection im actually not sure how reliable is this even in slack, but in general, it can be useful, but im not sure how to solve it elegantly, when the chat runs remotely... maybe we should just spawn a loop at the background, which gathers idleness status from the OS and uploads it when it changes, into world readable files and the remote clients can just check those file whenever they want. 4. extra status indication with automatic expiry, eg when someone is away from the keyboard, coz they are having lunch we do use this feature often and it's a really helpful regarding when can we expect a response from someone. again, quite simple to model this as a plain text file and we can even use emojis, to have a very similar effect to setting " lunch" on slack. ppl would need to know what's the emoji selector shortcut though... like cmd-ctrl-space on macos. 5. text search across all channels/rooms assuming the chat is being logged into files, then a recursive (rip)grep could work to some extent, but then from the search results one might want to get back to the context of the result too. 6. threads this complicates implementation a lot more, but we found it an obvious improvement over the single threaded IRC model of communication 7. having threads open on the side, so ppl can track 2 streams of comms at once at least it would require starting the chat app multiple times and do some window management to see them side-by-side now obviously all this can be done a lot simpler, but those implementations typically always lack somehow. not sure why is that... see https://cancel.fm/ripcord/ https://cancel.fm/ripcord/ or http://www.altme.com/what.html http://www.altme.com/what.html the REBOL 3 programming language even had a quite full featured, text-mode chat built in: http://www.rebol.com/r3/docs/functions/chat.html http://www.rebol.com/r3/docs/functions/chat.html !
qudat 3y ago
Slack and discord have screen sharing and voice chat. These are not sideline features. They are pretty critical features to its market dominance.
- leovander 3y ago
  Critical yet feels like they are going down in quality.
  - justrealist 3y ago
    99% of the issues I've seen for these features have been the OS making it increasingly a pain in the ass to grant an application permission to gain full-screen control or camera/mic access. Not really Slack's fault as far as I can tell.
  - duped 3y ago
    How so?
numpad0 3y ago
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?
- linschn 3y ago
  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 ?
  - lelanthran 3y ago
    > 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 ? I'm not sure that it would be difficult to wrap that up in a web interface running on a single server that does nothing but execute those command-line calls - auth, data and everything but session would be managed by the web server. You could perhaps even make a local GUI application that spawns ssh once and reads+writes to it, and have your 90% slack functionality done in a weekend.
    - sharikous 3y ago
      Yes and this GUI application should be cross platform so make it Electron. Wait, there has been a leak from the company so we need some security staff on it and maybe mandated TFA. And it's nice to have a way to call people and not only chat. I wonder if there is already an app that does that, even if it's bloated it would be more convenient...
mappu 3y ago
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.
- lloeki 3y ago
  > Most current distros prevent you from making setuid bash scripts _any_ shebang script really... except perl scripts, because perl has taint mode turned on automatically when uid != euid https://perldoc.perl.org/perlsec#Taint-mode https://perldoc.perl.org/perlsec#Taint-mode Note that there may be a fundamental race condition on some systems: https://perldoc.perl.org/perlsec#Shebang-Race-Condition https://perldoc.perl.org/perlsec#Shebang-Race-Condition Also see the noted use of `sudo -T`: https://perldoc.perl.org/perlsec#Using-Sudo https://perldoc.perl.org/perlsec#Using-Sudo I lament the recent removal of taint mode from Ruby :( as tainting is a powerful mechanism that could go way beyond scripts: imagine Rack / Rails #html_safe but via tainting so it could have worked more thoroughly (e.g concatenate/interpolate/format a tainted user string into a SQL snippet would blow up, preventing a whole class of SQL injections by design) Some folks used to use taint for CGI/mod_perl to such great effect. It's not a magic bullet by any means (security is hard!) but it's a really effective tool still.
- linschn 3y ago
  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_wrapper.c https://gitlab.com/edouardklein/suc/-/blob/master/suc_wrappe...
- throwawaymobule 3y ago
  Is there even distros that let you do it? When I wanted to do this myself all things I read led me to believe that the setuid doesn't apply because the file itself isn't running, the thing in your shebang is. Until I found the wrapper file in the GitLab repo, I was holding out hope as I read through that there was some way.
atulvi 3y ago
cool but misleading title
KRAKRISMOTT 3y ago
Unix default security mechanisms are not enough, otherwise tools like KVM/Firecracker and gVisor won't be the standard for all cloud hosting. Unix just wasn't built to sandbox truly hostile code.
000ooo000 3y ago
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 functionality is not 100% of these applications. They're built in completely different environments, and so to attack the status quo as bloated seems like some kind of warped Stockton Rush esque take on things. Don't get me wrong, there's bloat in software, but "look ma', I built a submarine from bits and pieces - told you those fancy submarines are stupid" doesn't seem like the put-down I think the author would like it to be.
- benrutter 3y ago
  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.
- mid-kid 3y ago
  > 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? The point was that most of these things become less relevant when the surface area of the codebase gets smaller. Individual utilities are generally easier to understand, test and debug as separate units, logging is already baked into the system (syslog, anyone?), and why would you need analytics?
  - lolinder 3y ago
    So what do you do when your customers say "this is great, when are you adding screen sharing"? Where do voice calls fit into this architecture, do we just add another UNIX util and stream the bits over SSH? Furthermore, debugging may be "easier" insofar as the units are discrete (though any good modular architecture will have the same advantage), but what do you do when you find a bug? If you're running a business, you can't be in a place where you're just submitting it upstream and telling your customers that every single bug is waiting for a vendor fix. So now you have to take ownership of maintaining and repairing each and every UNIX utility you use. In what world is that easier than having 500k lines of Go in a consistent company style? Joel Spolsky's advice is pertinent [0]: > If it’s a core business function — do it yourself, no matter what. https://www.joelonsoftware.com/2001/10/14/in-defense-of-not-invented-here-syndrome/ https://www.joelonsoftware.com/2001/10/14/in-defense-of-not-...
shreyshnaccount 3y ago
This is pretty cool. Only need to (re) solve the discoverability problem and we will have a better social network than twitter and reddit back
- kristopolous 3y ago
  Finger and whois. It was solved over 40 years ago. That's the thing with social networking. There's a few core problems and it's been solved many times. Such as in 1973 at Community Memory in Berkeley: https://en.wikipedia.org/wiki/Community_Memory https://en.wikipedia.org/wiki/Community_Memory Or through newspaper classifieds ads, French salons, compuserve, bars, aol, cb radio, friendster, phone phreaking party lines, dialup bbses, icq, irc, myspace, Facebook, netnews, whois/finger/talk/uucp. If you read Carolyn Marvin's book, "When old Technologies Were New" (1988) you'll see her documentation of this in its first digital form - via lonely telegraph operators chatting with each other in the 19th century. It's the network, not the medium, that matters.
  - shreyshnaccount 3y ago
    It needs to align with the evolution of content consumption, which I'm sure it can. That's why i said (re)
  - shreyshnaccount 3y ago
    This is a great take. Added the book to my list
dclowd9901 3y ago
Cool. _proceeds to sign up for slack._
onetom 3y ago
what do i do after i sign up to the-dam.org ? i did not get any email after the payment and ssh-ing doesn't work either. (i just get a `Permission denied (publickey)`)
- 59nadir 3y ago
  Same for me. I suspect maybe they add the public keys manually and haven't gotten around to it yet.
  - linschn 3y ago
    That's exactly what happened :) thank you.
- linschn 3y ago
  To HN readers: this has been sorted out, adding user is a semi-manual process and I was asleep :)
lynx23 3y ago
While we are at bloated things reimplemented in a few lines of shell: https://github.com/mlang/openai-kiss https://github.com/mlang/openai-kiss is my CLI client for ChatGPT. No Python, just curl and jq.
twic 3y ago
Thought this was going to be about ytalk!
rakoo 3y ago
See also ii (https://tools.suckless.org/ii/ https://tools.suckless.org/ii/) doing something similar but on irc directly: use a single standard file for all conversation, auth and access is managed by the irc network directly and there are many UIs already. Like the article, a plugin is anything that reads a file and writes into another.
- rnmmrnm 3y ago
  or jj (https://github.com/aaronNGi/jj https://github.com/aaronNGi/jj) in awk.
galkk 3y ago
Some claim that IRC is simple and one doesn't really need anything else. For some, IRC is the example why slack/discord won.
zokier 3y ago
Unfortunately I don't see any real way to avoid suid here, otherwise neat experiment. Posix ACLs might help, but the crucial part is prefixing the username to the message which requires privilege Lots of unix facilities are criminally underutilized in modern systems
- throwawaymobule 3y ago
  Run a daemon with the right userid to do the writing, and have it make a pipe device for each user to write lines into. I don't know how much effort is meant to be put into securing this from impersonation, but info can be pulled out of /proc/ if the permissions are set up right.
  - zokier 3y ago
    Hmm apparently there is this thing SO_PEERCRED which gives you the identity of the client connected to unix socket, that might fit here quite well.
CodeCompost 3y ago
5 lines of bash... ... and over 50 years of operating systems development.
- ajsnigrutin 3y ago
  and you still need to give ssh access to people just to chat :)
  - themoonisachees 3y ago
    The aforementioned 50 years of OS development have given us facilities through which you can very tightly control what access you give to ssh clients, in a tried and tested way. The authors are right when they say that sshd and unix users are probably the most frature-full auth scheme in existence.
- linschn 3y ago
  Exactly ! Too many software project just ignore the underlying abstractions of the OS they run on. I feel weird with all this virtualization stuff, like we're missing something obvious. Rob Pike said in 2000 that systems research is irrelevant http://doc.cat-v.org/bell_labs/utah2000/ http://doc.cat-v.org/bell_labs/utah2000/ and I'd like to think that if we went back to simple tools like this we could make it somewhat relevant again.
jamespo 3y ago
I guess no one remembers ytalk then https://linux.die.net/man/1/ytalk https://linux.die.net/man/1/ytalk
- linschn 3y ago
  I should really mention it in the article. I actually tried to install and use it before writing suc but was unable to.
pgtan 3y ago
This bash code is a parade example how NOT to write scripts.
- linschn 3y ago
  What would you change about it ? I'd be happy to learn how to write better code.
  - pgtan 3y ago
    OK, for starter the while loop. Main rule of writing shell scripts is, Use The Shell, Luke. Don't start external programs, if your shell (which is already running) can do it. "while /usr/bin/true" is nonsense, every time an external program gets executed for nothing. There are plenty of bash (since this shell is used in the example) internals, which evaluate to true, like ":", "test 1", "(( 1 ))", maybe others too. So "while :" should be better. But why even use dummy true statement, since the loop terminates with read? You can put the read as argument to while directly: "while read -r line; do" ... Same with echo and date. Just use one single printf builtin. while read -r line ; do printf '%(%FT%T%z)T %-9s %s' -1 "$(/usr/bin/id --user --name --real)" "$line" ; done
    - linschn 3y ago
      Thanks for the pointer about the useless use of true. Using builtins may be a security risk as they can be overloaded (hence the use of full paths everywhere). I did not know about bash's extension of printf to print a date. I need to use the builtin to use it though. But I've received good advice elsewhere on how to do that securely, so I'll do it and do a write-up because it's not information that's easy to come by. Your advice is very helpful, thank you.
      - TristanBall 3y ago
        Bash and zsh both allow: function /usr/bin/cat { echo hello; }; /usr/bin/cat hello So specifying a path isn't as useful as it seems
      - 3y ago
boffinAudio 3y ago
$ 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 .. ;){
- linschn 3y ago
  I couldn't make talk or wall work on a modern linux system. That's a shame.
  - themoonisachees 3y ago
    Just a few years ago in university the lab computers were running debian 10 and the sysadmin would make announcements about linux-specific infra outages through a script that ssh'd into every machine and wall'd the outage message. We would often get people using lab computers remotely and you could talk or wall them to tell them you were rebooting soon. Good times.
    - boffinAudio 3y ago
      I think the whole idea of using a Linux system as the host for a social network is an idea whose time has definitely come. Disclaimer: Have a "The Wall" account somewhere. What goes around, comes around ..
Aeolun 3y ago
Well, yeah, if I use a bunch of other programs to do a bunch of stuff, and then don’t include those lines in my total I can get pretty far too.
- palata 3y ago
  Do you count the lines that Slack needs to get the text to appear on your screen? Or to send the network packets? Do you count the lines involved in all the routers on the way, too?
peter_d_sherman 3y ago
>"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!
- linschn 3y ago
  Your enthusiasm made me smile :)
alexpotato 3y ago
This reminds me of this article about using command line tools vs hadoop: https://adamdrake.com/command-line-tools-can-be-235x-faster-than-your-hadoop-cluster.html https://adamdrake.com/command-line-tools-can-be-235x-faster-...
agentultra 3y ago
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 you can probably figure out how to use Slack.
- BenLloydPearson 3y ago
  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.
- realitythreek 3y ago
  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.
memetomancer 3y ago
I'm immediately reminded of "Master Foo and the Ten Thousand Lines": http://catb.org/~esr/writings/unix-koans/ten-thousand.html http://catb.org/~esr/writings/unix-koans/ten-thousand.html Master Foo once said to a visiting programmer: “There is more Unix-nature in one line of shell script than there is in ten thousand lines of C.”
bryancoxwell 3y ago
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?
- ericbarrett 3y ago
  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!
- revelio 3y ago
  Do they require a web frontend, or do you just want one? Because you could argue a chat program requires a web frontend, but suc doesn't use one regardless. bash is concise but there are other languages nearly as concise. It'd make more sense to use them rather than go+bash, once you cross the rubicon of not relying entirely on stuff that comes with UNIX out of the box.
- themoonisachees 3y ago
  If your server is served by apache or ngnix, you don't have to call into PHP/other languages in order to return bash commands. You can define a route in which pages accessed are fed to a bash script and stdout gets piped back to the client.
pigeons 3y ago
man 1 talk
siilikuin 3y ago
Chapter 8 of The Linux Programming Interface mentions that applications running on Linux have basically 2 options for authentication: * Roll it themselves, maintain the database and all that jazz * Delegate it to the (very robust, very mature) Linux user authentication stuff Ever since reading that I've found myself wondering why more apps don't simply use SSH keypairs for authentication, given that they're already such a battletested mechanism. I get the whole "no MFA!" argument, but still.
- pjlegato 3y ago
  SSH has supported MFA for decades: https://www.google.com/search?q=ssh+mfa https://www.google.com/search?q=ssh+mfa
- themoonisachees 3y ago
  If we really wanted MFA, we could roll a PAM module, and whatever pushes SSH authorized keys could also push MFA seeds. But IMO this would protect against very unusual attacks and annoy ssh agents users everywhere.
  - throwawaymobule 3y ago
    Doing MFA for ssh like that would satisfy some compliance issues, wherever that matters. Probably key+pass.
    - siilikuin 3y ago
      Lol. I actually use `ssh` with 2FA at my own job, I was just having some fun nerdsniping. You're right, it's very valuable for compliance reasons
- deleted 3y ago
  [deleted]
aidenn0 3y ago
can someone post the following to a channel and delete everybody's home directory that reads it with usuc? : rm -rf ~/ [edit] They cannot. On careful rereading usuc passes the data through the pipe when writing a message, not reading it. So the channel is just full of raw terminal escape codes, if I understand correctly.
- linschn 3y ago
  This is correct, the command is run by the user writing the message. Only the output lies in the channel.
chias 3y ago
In general, composing Unix commands is a very powerful means to construct complex applications... poorly, with no real pathways to fixing their shortcomings. I believe the traditional "Unix Way" is to gloss over said shortcomings and pretend they don't exist, and when that fails, move the goalposts and argue that they don't exist "in the real world". For example, what combination of shell commands can I use to output the number of files in a directory? Hint: it's a trick question, you can't.
- memetomancer 3y ago
  |For example, what combination of shell commands can I use to output the number of files in a directory? Hint: it probably isn't what you think it is, if it's even possible. `find . -type f | wc -l`
  - jcynix 3y ago
    Good first attempt. But: counts two links to the same file twice. That is: touch foo; ln foo bar Is this one file or two "links" to the same file? ;-0
    - bandrami 3y ago
      You said files, not inodes. Those are two files sharing one inode. If you want to count inodes, specify that in the question.
      - jcynix 3y ago
        I'm not the one who posed the question. And: file, filename, inode, ...? What's what and what's exactly to be counted?
        memetomancer 3y ago
        the inode is the important thing when all is said and done. It is flexible in that it can contain all the metadata needed to present a file to a process. Sometimes that metadata is a list of blocks in the filesystem. sometimes it points to another inode. I think of it like an old-timey 'card catalog'. You have a bunch of tiny drawers filled with cards. Some of the cards are big and blank spacers with a prominent tab sticking above the normal top edges (Directory). Sometimes you have a card that points to another card elsewhere in the catalog (link). Sometimes you find the details of a specific book on a specific shelf (block data). Point is, they are all cards. The comment essentially asked for a command to say 'how many cards between these two spacers'. It's a "trick" question as old as usenet to spring the distinction between link inodes and list of blocks inodes and say "Ah-HAH!! gotcha", but in reality it's a silly game of jumping levels, misdirecting semantics and prey upon the distribution of understanding in a forum for personal glory. The inode is the item, it is the card that is being counted, no matter what is printed on it. imho.
yayitswei 3y ago
Would be interesting to compile a "spawn of unix" diagram similar to the craigslist diagram, of startups that carve out niches of unix functionality. https://thegongshow.tumblr.com/post/345941486/the-spawn-of-craigslist-like-most-vcs-that-focus https://thegongshow.tumblr.com/post/345941486/the-spawn-of-c... ftp/rsync => Dropbox suc => Slack ...
logicprog 3y ago
This is an incredibly cool Showcase of the power of Unix command line utilities and their composability. However, I have to say, as someone who recently got into amateur system administration for a server that hosts several services I and my friends use m, I would not want to be responsible for maintaining this!
- linschn 3y ago
  Yeah in the tests I ran while designing it, it became apparent that keeping everything in order was kind of a pain. However, with Guix it actually becomes quite easy. There is not "state" in the system: the system is simply a function of your system declaration (the /etc/config.scm file) that defines the whole OS. No need to remember what to chmod chown, etc.
liveoneggs 3y ago
This is different but I'm surprised it doesn't mention talk(1) https://man.netbsd.org/talk.1 https://man.netbsd.org/talk.1
- Fnoord 3y ago
  Or write(2) [1]. I was thinking immediately about ntalk though, because its the last time I used such on the same machine (because IRC wasn't encrypted back then). The nice thing about that, is that you can have it listen locally only, and then one needs a user account on that machine. So its great for say SDF but also these larger clusters and all that. And it doesn't do auth; you let PAM or BSD_Auth do that. It doesn't do sockets or encryption, you let TLS do that. And you could just use SSH to get to a secure shell, using tmux and (n)talk from there. Goes without saying (n)talk isn't 5 lines of bash as its written in C. [1] https://man7.org/linux/man-pages/man2/write.2.html https://man7.org/linux/man-pages/man2/write.2.html
cozzyd 3y ago
one nicety that Slack etc. can't match is that this works on a local network even if internet access is lost (and doesn't slow down with terrible network latency). Going to install this on our server on the Greenland ice shelf...
DrNosferatu 3y ago
What about a Simple Unix ChatGPT? But for the terminal. What options are there and what are your experiences?
esbeeb 3y ago
I actually run/manage Mattermost Team server (and know/used/administered Unix/Linux for 25+ years), and it's not a fair comparison. BTW: The relatively low RAM usage and speed of Mattermost is underappreciated, IMHO. We all know "suc" is merely a tongue-in-cheek thought exercise. :) Good luck getting 100's of millions of Twitter/Bluesky/Threads users to even use Mastodon. Nobody but geeks can use "suc", Mattermost can be used by a far larger proportion of people. Good recently posted HN-linked article about how most users have a lot less skill than you think: "The Distribution of Users’ Computer Skills: Worse Than You Think": https://www.nngroup.com/articles/computer-skill-levels/ https://www.nngroup.com/articles/computer-skill-levels/

403 points by thm 3y ago

UNIX shell is good like that, that you can combine thing in shell scripts and command-line you can make such a combined program, if you are using programs that are designed to support that (unfortunately, too many modern programs don't, although some do). However, is there a race condition with writing to the files? Since it is append mode, I would expect that would prevent other processes overwriting the file, although would it prevent other processes writing in the middle of a line if it gets interrupted? Actually, I don't know. I had made a simple two user chat system with logging using ts, tee, and nc; using a shell script with only a single line of code. This produces two log files, one for sending and one for receiving; however, I can then use cat and sort to interleave the logs into a single log file.

pfych 3y ago

Very 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.

londons_explore 3y ago

Functionally, this is nearly the same as slack, but it's missing the aggressive venture capital funding and marketing team...

peeters 3y ago
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).
- esafak 3y ago
  I was pitching a related concept to a young investor lately, and she had not heard of IRC. If you stick around long enough, all that is old is new again. If you can profit from this, it's great. If you can't, it is a source of frustration.
- raincole 3y ago
  In the way a pen and a very long tape is "same functionaltiy as a modern CPU".
- linschn 3y ago
  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.
  - BenLloydPearson 3y ago
    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.
  - progval 3y ago
    You don't need a bouncer for chat history when connecting to (the few) servers implementing https://ircv3.net/specs/extensions/chathistory https://ircv3.net/specs/extensions/chathistory

eyelidlessness 3y ago

> 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.

kitchi 3y ago
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.
- eyelidlessness 3y ago
  > 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.

Gigachad 3y ago

How do I make a call with this?

eur0pa 3y ago
Use your phone
- esafak 3y ago
  I suppose I should send an email instead of using suc then?
ramses0 3y ago
cat /dev/audio | <( mkfifo && netcat ) ...semi-unironically... (whoops, forgot the gzip/gunzip filters...)
- linschn 3y ago
  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...
  - rvense 3y ago
    I think the main issue would be the buffering existing tools are likely to assume. You don't need more than a few hundred ms of latency for a phone call to start feeling really weird.
  - shrubble 3y ago
    If you went with the heavier-weight use of Asterisk, you could have softphones authenticated to Asterisk, but, no inbound calls from the softphones would be accepted. Only if 1 user sought to call another would Asterisk "dial" each softphone; which might be sufficient in terms of security (you would have to have a working SSH account to be called).
  - ramses0 3y ago

anonym29 3y ago

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 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.

photonerd 3y ago
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.
- jesuspiece 3y ago
  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
  - linschn 3y ago
    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.

spicybright 3y ago

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 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.

cornel_io 3y ago
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.
- linschn 3y ago
  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.
dclowd9901 3y ago
Big emphasis on “kind of”. “Here’s how to make $2 million dollars over night” _reads article_: “have $4 million in the bank…”
- cassepipe 3y ago
  I laughed reading your comparison but I don't agree. I clicked waiting for a shallow trick and found that there was indeed a trick, but not a shallow one at all This ability to bring complex capabilities to a chat system by leveraging so much of its ecosystem is truly amazing. Definitely worth the hn front page. And you only need basic shell literacy in order to use it, little more to understand it

wfme 3y ago

This is very reminiscent of the initial hn response to DropBox [0]. This is like saying that you can build a Tesla clone by attaching 3 pieces of wood together along with 4 wheels. Although it is technically cool, it misses practically all of what makes Slack so popular - UX. [0]: https://news.ycombinator.com/item?id=8863 https://news.ycombinator.com/item?id=8863

devmor 3y ago
>it misses practically all of what makes Slack so popular - UX I strongly disagree. Slack has nearly the same UX as every chat platform of the past 2-3 decades. It's a slightly change over AOL Instant Messenger. There's also a large amount of very similar software or straight-up slack clones that are not very popular at all. I would say what makes Slack so popular is how easy it is to set up and get running, both as a service and for every user, combined with the availability of easy integrations/plugins.
- thayne 3y ago
  > I would say what makes Slack so popular is how easy it is to set up and get running, both as a service and for every user, combined with the availability of easy integrations/plugins That is part of the User eXperience. I.e. UX.
- maxcoding 3y ago
  What you are describing is quite literally the UX, the user experience, and Slack overall has quite a good one. Although several of the newer features are somewhat lacking in that regard, like the threads feature.
- deleted 3y ago
  [deleted]
- onetom 3y ago
  there are a bunch of features in slack beyond the core chat stuff, like: 1. being connected to multiple communities and switching between them instantly this can be of course simply replaced by connecting to different servers in a tabbed terminal and use the terminal's built-in cmd-1/2/... shortcut, which happens to be the same as in slack. 2. meta data about others, like their timezone or how to pronounce their name is quite important for distributed team work this can be approximated by a world readable file on the chat server in every user's home, like .plan or motd files (https://github.com/ESWAT/john-carmack-plan-archive https://github.com/ESWAT/john-carmack-plan-archive) 3. automatic idleness detection im actually not sure how reliable is this even in slack, but in general, it can be useful, but im not sure how to solve it elegantly, when the chat runs remotely... maybe we should just spawn a loop at the background, which gathers idleness status from the OS and uploads it when it changes, into world readable files and the remote clients can just check those file whenever they want. 4. extra status indication with automatic expiry, eg when someone is away from the keyboard, coz they are having lunch we do use this feature often and it's a really helpful regarding when can we expect a response from someone. again, quite simple to model this as a plain text file and we can even use emojis, to have a very similar effect to setting " lunch" on slack. ppl would need to know what's the emoji selector shortcut though... like cmd-ctrl-space on macos. 5. text search across all channels/rooms assuming the chat is being logged into files, then a recursive (rip)grep could work to some extent, but then from the search results one might want to get back to the context of the result too. 6. threads this complicates implementation a lot more, but we found it an obvious improvement over the single threaded IRC model of communication 7. having threads open on the side, so ppl can track 2 streams of comms at once at least it would require starting the chat app multiple times and do some window management to see them side-by-side now obviously all this can be done a lot simpler, but those implementations typically always lack somehow. not sure why is that... see https://cancel.fm/ripcord/ https://cancel.fm/ripcord/ or http://www.altme.com/what.html http://www.altme.com/what.html the REBOL 3 programming language even had a quite full featured, text-mode chat built in: http://www.rebol.com/r3/docs/functions/chat.html http://www.rebol.com/r3/docs/functions/chat.html !

qudat 3y ago

Slack and discord have screen sharing and voice chat. These are not sideline features. They are pretty critical features to its market dominance.

leovander 3y ago
Critical yet feels like they are going down in quality.
- justrealist 3y ago
  99% of the issues I've seen for these features have been the OS making it increasingly a pain in the ass to grant an application permission to gain full-screen control or camera/mic access. Not really Slack's fault as far as I can tell.
- duped 3y ago
  How so?

numpad0 3y ago

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?

linschn 3y ago
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 ?
- lelanthran 3y ago
  > 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 ? I'm not sure that it would be difficult to wrap that up in a web interface running on a single server that does nothing but execute those command-line calls - auth, data and everything but session would be managed by the web server. You could perhaps even make a local GUI application that spawns ssh once and reads+writes to it, and have your 90% slack functionality done in a weekend.
  - sharikous 3y ago
    Yes and this GUI application should be cross platform so make it Electron. Wait, there has been a leak from the company so we need some security staff on it and maybe mandated TFA. And it's nice to have a way to call people and not only chat. I wonder if there is already an app that does that, even if it's bloated it would be more convenient...

mappu 3y ago

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.

lloeki 3y ago
> Most current distros prevent you from making setuid bash scripts _any_ shebang script really... except perl scripts, because perl has taint mode turned on automatically when uid != euid https://perldoc.perl.org/perlsec#Taint-mode https://perldoc.perl.org/perlsec#Taint-mode Note that there may be a fundamental race condition on some systems: https://perldoc.perl.org/perlsec#Shebang-Race-Condition https://perldoc.perl.org/perlsec#Shebang-Race-Condition Also see the noted use of `sudo -T`: https://perldoc.perl.org/perlsec#Using-Sudo https://perldoc.perl.org/perlsec#Using-Sudo I lament the recent removal of taint mode from Ruby :( as tainting is a powerful mechanism that could go way beyond scripts: imagine Rack / Rails #html_safe but via tainting so it could have worked more thoroughly (e.g concatenate/interpolate/format a tainted user string into a SQL snippet would blow up, preventing a whole class of SQL injections by design) Some folks used to use taint for CGI/mod_perl to such great effect. It's not a magic bullet by any means (security is hard!) but it's a really effective tool still.
linschn 3y ago
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_wrapper.c https://gitlab.com/edouardklein/suc/-/blob/master/suc_wrappe...
throwawaymobule 3y ago
Is there even distros that let you do it? When I wanted to do this myself all things I read led me to believe that the setuid doesn't apply because the file itself isn't running, the thing in your shebang is. Until I found the wrapper file in the GitLab repo, I was holding out hope as I read through that there was some way.

atulvi 3y ago

cool but misleading title

KRAKRISMOTT 3y ago

Unix default security mechanisms are not enough, otherwise tools like KVM/Firecracker and gVisor won't be the standard for all cloud hosting. Unix just wasn't built to sandbox truly hostile code.

000ooo000 3y ago

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 functionality is not 100% of these applications. They're built in completely different environments, and so to attack the status quo as bloated seems like some kind of warped Stockton Rush esque take on things. Don't get me wrong, there's bloat in software, but "look ma', I built a submarine from bits and pieces - told you those fancy submarines are stupid" doesn't seem like the put-down I think the author would like it to be.

benrutter 3y ago
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.
mid-kid 3y ago
> 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? The point was that most of these things become less relevant when the surface area of the codebase gets smaller. Individual utilities are generally easier to understand, test and debug as separate units, logging is already baked into the system (syslog, anyone?), and why would you need analytics?
- lolinder 3y ago
  So what do you do when your customers say "this is great, when are you adding screen sharing"? Where do voice calls fit into this architecture, do we just add another UNIX util and stream the bits over SSH? Furthermore, debugging may be "easier" insofar as the units are discrete (though any good modular architecture will have the same advantage), but what do you do when you find a bug? If you're running a business, you can't be in a place where you're just submitting it upstream and telling your customers that every single bug is waiting for a vendor fix. So now you have to take ownership of maintaining and repairing each and every UNIX utility you use. In what world is that easier than having 500k lines of Go in a consistent company style? Joel Spolsky's advice is pertinent [0]: > If it’s a core business function — do it yourself, no matter what. https://www.joelonsoftware.com/2001/10/14/in-defense-of-not-invented-here-syndrome/ https://www.joelonsoftware.com/2001/10/14/in-defense-of-not-...

shreyshnaccount 3y ago

This is pretty cool. Only need to (re) solve the discoverability problem and we will have a better social network than twitter and reddit back

kristopolous 3y ago
Finger and whois. It was solved over 40 years ago. That's the thing with social networking. There's a few core problems and it's been solved many times. Such as in 1973 at Community Memory in Berkeley: https://en.wikipedia.org/wiki/Community_Memory https://en.wikipedia.org/wiki/Community_Memory Or through newspaper classifieds ads, French salons, compuserve, bars, aol, cb radio, friendster, phone phreaking party lines, dialup bbses, icq, irc, myspace, Facebook, netnews, whois/finger/talk/uucp. If you read Carolyn Marvin's book, "When old Technologies Were New" (1988) you'll see her documentation of this in its first digital form - via lonely telegraph operators chatting with each other in the 19th century. It's the network, not the medium, that matters.
- shreyshnaccount 3y ago
  It needs to align with the evolution of content consumption, which I'm sure it can. That's why i said (re)
- shreyshnaccount 3y ago
  This is a great take. Added the book to my list

dclowd9901 3y ago

Cool. _proceeds to sign up for slack._

onetom 3y ago

what do i do after i sign up to the-dam.org ? i did not get any email after the payment and ssh-ing doesn't work either. (i just get a `Permission denied (publickey)`)

59nadir 3y ago
Same for me. I suspect maybe they add the public keys manually and haven't gotten around to it yet.
- linschn 3y ago
  That's exactly what happened :) thank you.
linschn 3y ago
To HN readers: this has been sorted out, adding user is a semi-manual process and I was asleep :)

lynx23 3y ago

While we are at bloated things reimplemented in a few lines of shell: https://github.com/mlang/openai-kiss https://github.com/mlang/openai-kiss is my CLI client for ChatGPT. No Python, just curl and jq.

twic 3y ago

Thought this was going to be about ytalk!

rakoo 3y ago

See also ii (https://tools.suckless.org/ii/ https://tools.suckless.org/ii/) doing something similar but on irc directly: use a single standard file for all conversation, auth and access is managed by the irc network directly and there are many UIs already. Like the article, a plugin is anything that reads a file and writes into another.

rnmmrnm 3y ago
or jj (https://github.com/aaronNGi/jj https://github.com/aaronNGi/jj) in awk.

galkk 3y ago

Some claim that IRC is simple and one doesn't really need anything else. For some, IRC is the example why slack/discord won.

zokier 3y ago

Unfortunately I don't see any real way to avoid suid here, otherwise neat experiment. Posix ACLs might help, but the crucial part is prefixing the username to the message which requires privilege Lots of unix facilities are criminally underutilized in modern systems

throwawaymobule 3y ago
Run a daemon with the right userid to do the writing, and have it make a pipe device for each user to write lines into. I don't know how much effort is meant to be put into securing this from impersonation, but info can be pulled out of /proc/ if the permissions are set up right.
- zokier 3y ago
  Hmm apparently there is this thing SO_PEERCRED which gives you the identity of the client connected to unix socket, that might fit here quite well.

CodeCompost 3y ago

5 lines of bash... ... and over 50 years of operating systems development.

ajsnigrutin 3y ago
and you still need to give ssh access to people just to chat :)
- themoonisachees 3y ago
  The aforementioned 50 years of OS development have given us facilities through which you can very tightly control what access you give to ssh clients, in a tried and tested way. The authors are right when they say that sshd and unix users are probably the most frature-full auth scheme in existence.
linschn 3y ago
Exactly ! Too many software project just ignore the underlying abstractions of the OS they run on. I feel weird with all this virtualization stuff, like we're missing something obvious. Rob Pike said in 2000 that systems research is irrelevant http://doc.cat-v.org/bell_labs/utah2000/ http://doc.cat-v.org/bell_labs/utah2000/ and I'd like to think that if we went back to simple tools like this we could make it somewhat relevant again.

jamespo 3y ago

I guess no one remembers ytalk then https://linux.die.net/man/1/ytalk https://linux.die.net/man/1/ytalk

linschn 3y ago
I should really mention it in the article. I actually tried to install and use it before writing suc but was unable to.

pgtan 3y ago

This bash code is a parade example how NOT to write scripts.

linschn 3y ago
What would you change about it ? I'd be happy to learn how to write better code.
- pgtan 3y ago
  OK, for starter the while loop. Main rule of writing shell scripts is, Use The Shell, Luke. Don't start external programs, if your shell (which is already running) can do it. "while /usr/bin/true" is nonsense, every time an external program gets executed for nothing. There are plenty of bash (since this shell is used in the example) internals, which evaluate to true, like ":", "test 1", "(( 1 ))", maybe others too. So "while :" should be better. But why even use dummy true statement, since the loop terminates with read? You can put the read as argument to while directly: "while read -r line; do" ... Same with echo and date. Just use one single printf builtin. while read -r line ; do printf '%(%FT%T%z)T %-9s %s' -1 "$(/usr/bin/id --user --name --real)" "$line" ; done
  - linschn 3y ago
    Thanks for the pointer about the useless use of true. Using builtins may be a security risk as they can be overloaded (hence the use of full paths everywhere). I did not know about bash's extension of printf to print a date. I need to use the builtin to use it though. But I've received good advice elsewhere on how to do that securely, so I'll do it and do a write-up because it's not information that's easy to come by. Your advice is very helpful, thank you.
    - TristanBall 3y ago
      Bash and zsh both allow: function /usr/bin/cat { echo hello; }; /usr/bin/cat hello So specifying a path isn't as useful as it seems
    - 3y ago

boffinAudio 3y ago

$ 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 .. ;){

linschn 3y ago
I couldn't make talk or wall work on a modern linux system. That's a shame.
- themoonisachees 3y ago
  Just a few years ago in university the lab computers were running debian 10 and the sysadmin would make announcements about linux-specific infra outages through a script that ssh'd into every machine and wall'd the outage message. We would often get people using lab computers remotely and you could talk or wall them to tell them you were rebooting soon. Good times.
  - boffinAudio 3y ago
    I think the whole idea of using a Linux system as the host for a social network is an idea whose time has definitely come. Disclaimer: Have a "The Wall" account somewhere. What goes around, comes around ..

Aeolun 3y ago

Well, yeah, if I use a bunch of other programs to do a bunch of stuff, and then don’t include those lines in my total I can get pretty far too.

palata 3y ago
Do you count the lines that Slack needs to get the text to appear on your screen? Or to send the network packets? Do you count the lines involved in all the routers on the way, too?

peter_d_sherman 3y ago

>"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!

linschn 3y ago
Your enthusiasm made me smile :)

alexpotato 3y ago

This reminds me of this article about using command line tools vs hadoop: https://adamdrake.com/command-line-tools-can-be-235x-faster-than-your-hadoop-cluster.html https://adamdrake.com/command-line-tools-can-be-235x-faster-...

agentultra 3y ago

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 you can probably figure out how to use Slack.

BenLloydPearson 3y ago
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.
realitythreek 3y ago
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.

memetomancer 3y ago

I'm immediately reminded of "Master Foo and the Ten Thousand Lines": http://catb.org/~esr/writings/unix-koans/ten-thousand.html http://catb.org/~esr/writings/unix-koans/ten-thousand.html Master Foo once said to a visiting programmer: “There is more Unix-nature in one line of shell script than there is in ten thousand lines of C.”

bryancoxwell 3y ago

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?

ericbarrett 3y ago
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!
revelio 3y ago
Do they require a web frontend, or do you just want one? Because you could argue a chat program requires a web frontend, but suc doesn't use one regardless. bash is concise but there are other languages nearly as concise. It'd make more sense to use them rather than go+bash, once you cross the rubicon of not relying entirely on stuff that comes with UNIX out of the box.
themoonisachees 3y ago
If your server is served by apache or ngnix, you don't have to call into PHP/other languages in order to return bash commands. You can define a route in which pages accessed are fed to a bash script and stdout gets piped back to the client.

pigeons 3y ago

man 1 talk

siilikuin 3y ago

Chapter 8 of The Linux Programming Interface mentions that applications running on Linux have basically 2 options for authentication: * Roll it themselves, maintain the database and all that jazz * Delegate it to the (very robust, very mature) Linux user authentication stuff Ever since reading that I've found myself wondering why more apps don't simply use SSH keypairs for authentication, given that they're already such a battletested mechanism. I get the whole "no MFA!" argument, but still.

pjlegato 3y ago
SSH has supported MFA for decades: https://www.google.com/search?q=ssh+mfa https://www.google.com/search?q=ssh+mfa
themoonisachees 3y ago
If we really wanted MFA, we could roll a PAM module, and whatever pushes SSH authorized keys could also push MFA seeds. But IMO this would protect against very unusual attacks and annoy ssh agents users everywhere.
- throwawaymobule 3y ago
  Doing MFA for ssh like that would satisfy some compliance issues, wherever that matters. Probably key+pass.
  - siilikuin 3y ago
    Lol. I actually use `ssh` with 2FA at my own job, I was just having some fun nerdsniping. You're right, it's very valuable for compliance reasons
deleted 3y ago
[deleted]

aidenn0 3y ago

can someone post the following to a channel and delete everybody's home directory that reads it with usuc? : rm -rf ~/ [edit] They cannot. On careful rereading usuc passes the data through the pipe when writing a message, not reading it. So the channel is just full of raw terminal escape codes, if I understand correctly.

linschn 3y ago
This is correct, the command is run by the user writing the message. Only the output lies in the channel.

chias 3y ago

In general, composing Unix commands is a very powerful means to construct complex applications... poorly, with no real pathways to fixing their shortcomings. I believe the traditional "Unix Way" is to gloss over said shortcomings and pretend they don't exist, and when that fails, move the goalposts and argue that they don't exist "in the real world". For example, what combination of shell commands can I use to output the number of files in a directory? Hint: it's a trick question, you can't.

memetomancer 3y ago
|For example, what combination of shell commands can I use to output the number of files in a directory? Hint: it probably isn't what you think it is, if it's even possible. `find . -type f | wc -l`
- jcynix 3y ago
  Good first attempt. But: counts two links to the same file twice. That is: touch foo; ln foo bar Is this one file or two "links" to the same file? ;-0
  - bandrami 3y ago
    You said files, not inodes. Those are two files sharing one inode. If you want to count inodes, specify that in the question.
    - jcynix 3y ago
      I'm not the one who posed the question. And: file, filename, inode, ...? What's what and what's exactly to be counted?
      - memetomancer 3y ago
        the inode is the important thing when all is said and done. It is flexible in that it can contain all the metadata needed to present a file to a process. Sometimes that metadata is a list of blocks in the filesystem. sometimes it points to another inode. I think of it like an old-timey 'card catalog'. You have a bunch of tiny drawers filled with cards. Some of the cards are big and blank spacers with a prominent tab sticking above the normal top edges (Directory). Sometimes you have a card that points to another card elsewhere in the catalog (link). Sometimes you find the details of a specific book on a specific shelf (block data). Point is, they are all cards. The comment essentially asked for a command to say 'how many cards between these two spacers'. It's a "trick" question as old as usenet to spring the distinction between link inodes and list of blocks inodes and say "Ah-HAH!! gotcha", but in reality it's a silly game of jumping levels, misdirecting semantics and prey upon the distribution of understanding in a forum for personal glory. The inode is the item, it is the card that is being counted, no matter what is printed on it. imho.

yayitswei 3y ago

Would be interesting to compile a "spawn of unix" diagram similar to the craigslist diagram, of startups that carve out niches of unix functionality. https://thegongshow.tumblr.com/post/345941486/the-spawn-of-craigslist-like-most-vcs-that-focus https://thegongshow.tumblr.com/post/345941486/the-spawn-of-c... ftp/rsync => Dropbox suc => Slack ...

logicprog 3y ago

This is an incredibly cool Showcase of the power of Unix command line utilities and their composability. However, I have to say, as someone who recently got into amateur system administration for a server that hosts several services I and my friends use m, I would not want to be responsible for maintaining this!

linschn 3y ago
Yeah in the tests I ran while designing it, it became apparent that keeping everything in order was kind of a pain. However, with Guix it actually becomes quite easy. There is not "state" in the system: the system is simply a function of your system declaration (the /etc/config.scm file) that defines the whole OS. No need to remember what to chmod chown, etc.

liveoneggs 3y ago

This is different but I'm surprised it doesn't mention talk(1) https://man.netbsd.org/talk.1 https://man.netbsd.org/talk.1

Fnoord 3y ago
Or write(2) [1]. I was thinking immediately about ntalk though, because its the last time I used such on the same machine (because IRC wasn't encrypted back then). The nice thing about that, is that you can have it listen locally only, and then one needs a user account on that machine. So its great for say SDF but also these larger clusters and all that. And it doesn't do auth; you let PAM or BSD_Auth do that. It doesn't do sockets or encryption, you let TLS do that. And you could just use SSH to get to a secure shell, using tmux and (n)talk from there. Goes without saying (n)talk isn't 5 lines of bash as its written in C. [1] https://man7.org/linux/man-pages/man2/write.2.html https://man7.org/linux/man-pages/man2/write.2.html

cozzyd 3y ago

one nicety that Slack etc. can't match is that this works on a local network even if internet access is lost (and doesn't slow down with terrible network latency). Going to install this on our server on the Greenland ice shelf...

DrNosferatu 3y ago

What about a Simple Unix ChatGPT? But for the terminal. What options are there and what are your experiences?

esbeeb 3y ago

I actually run/manage Mattermost Team server (and know/used/administered Unix/Linux for 25+ years), and it's not a fair comparison. BTW: The relatively low RAM usage and speed of Mattermost is underappreciated, IMHO. We all know "suc" is merely a tongue-in-cheek thought exercise. :) Good luck getting 100's of millions of Twitter/Bluesky/Threads users to even use Mastodon. Nobody but geeks can use "suc", Mattermost can be used by a far larger proportion of people. Good recently posted HN-linked article about how most users have a lot less skill than you think: "The Distribution of Users’ Computer Skills: Worse Than You Think": https://www.nngroup.com/articles/computer-skill-levels/ https://www.nngroup.com/articles/computer-skill-levels/