91–100 of 175 posts
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!
Earlier quoted context omitted.
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...
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…
"Append-only files" would be a great fit here: to ensure regular users and bots don't modify others' posts. Sadly this Plan 9 functionality is not ported to Linux yet. That's a permission bit, similar to "read" or "write", but even more specific.
https://adamdrake.com/command-line-tools-can-be-235x-faster-...
Earlier quoted context omitted.
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...
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…
> 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 i…
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-...
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.
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.”
Earlier quoted context omitted.
Big emphasis on “kind of”. “Here’s how to make $2 million dollars over night” _reads article_: “have $4 million in the bank…”
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
Earlier quoted context omitted.
"Append-only files" would be a great fit here: to ensure regular users and bots don't modify others' posts. Sadly this Plan 9 functionality is not ported to Linux yet. That's a permission bit, similar to "read" or "write", but even more specific.
Not so great if you're talking about real use cases where moderation is mandatory.