The design philosophy of Unix is fairly straightforward. Software should do one thing as simply as possible, and do that one thing only. As a design principle this is sound advice even well outside of the realm of Unix, and indeed software in general, but that doesn’t stop modern software packages from being too large for their own good. So, if you’re tired of bloated chat programs like Slack or Mattermost with their millions of lines of code, you might instead favor something like Simple Unix Chat (suc).
The idea is that suc can perform almost all modern chat functions in only five lines of Bash, supporting rich-text chat, file sharing, access control, and encryption. These five lines, though, only perform the core function of suc — which is to write text to a file on the system. Indeed, suc makes liberal use of plenty of other Unix services which do not add to the line counts, such as the use of SSH to handle authentication. It also relies on some other common Unix system features to handle things like ownership and access for the text files that host the text for the chat.
As channels are simply text files, it makes writing bots or other tools exceptionally simple. You can also easily pipe the output of commands directly into suc with one-liners that can do things like dump the output of make into a specific channel if compilation fails.
While it’s not likely that everyone will ditch tools like Slack to switch to something like this, it’s still an impressive demonstration of what can be done when designing around the Unix philosophy and taking advantage of system tools that already exist rather than reinventing the wheel and re-programming all of those tools into the application. Practices like this might decrease development time and increase the ease of developing cross-platform applications but they often also produce a less than desirable user experience.
Uh no, I’m not going to write something that will get me thrown off of Hackaday.
We use WhatsApp, so I’m not familiar with Slack, but I really don’t mind bloated tools. I want stuff that just works, without a bunch of separate parts to configure, that will then need more tools to manage the configuration….
Modularity is really cool, but I like applications that are fully encapsulated, that you don’t have to customize, so you know it’s just going to work and not have random issues at unpredictable times.
“I really don’t mind bloated tools” sounds what someone who doesn’t care about the current state of the enormous energy consumption by the IT sector nor the finiteness of our planet’s natural resources would say.
Except Moore’s Law took care of the “enormous energy consumption” so things balance out overall.
or like someone who understands that the energy consumption and finiteness of our planet’s natural resources can be credited 99.999999% to capitalist overlords. Let me remind you that burning stuff to make steam is still cheaper than every other option to produce energy – a total economic construct
Moving the burden to already burdened people (e.g. paper straws for the working class or tools that do the job much, much worse) is not viable, fair, logical, productive or effective
Sure. Let’s keep burning things to make steam because it’s cheap. Forget that it’s also the dirtiest and least efficient means of producing energy and we’ll sweep the huge environmental impact under the rug. You know? That very same environmental impact that quickly becomes a massive economic and health issue that impacts the “working class” most of all? Sound logic.
JTFC.
When you start with a false premise you will end at a stupid place. (check and check)
The fact is that you are not owned by ‘capitalist overlords’. Simply because you are _not_a_productive_asset_, same as the rest of the commies and the, so called, ‘working class’.
Nobody wants to own you, you are like a spoiled cat, a money pit that does no work. A liability not an asset.
Get over it. Once you understand this, you will understand why nobody cares.
You seem blind. Let’s oppress the populace for the sins of the wealthy. 🤦
Maybe it is not modular and can’t be configured but at least it consumes more resources.
In years to come folks will realize that Slack is the worst thing to happen to productivity this century, sucking away hours of engineers/developers time to chit-chat about irrelevant topics.
Exactly – Who would want to talk about life, interests, current affairs, tangentially relevant topics and other meditative things when you could be slaving away relentlessly.
Ha!
… people who work for a living?… … … ;D
Good. Productivity sucks.
preach ❤️
I didn’t see any mitigation for race conditions, and writes are not guaranteed to be atomic if two processes are writing to the same file without file locks. This is why things like syslog exist, if you had multiple things trying to write to /var/log/syslog directly you can get all manner of failures.
flock(1) would take care of locking without involving daemons.
[tldr: I love the concept but I think excluding the line-count of all of the unix-provided features and ignoring the complexities of scale makes this an unfair comparison.]
I’m in two minds about this. On one hand, this is undeniably an elegant, beautiful, and borderline genius solution.
On the other hand… the core concept is that, as the article summarises, “suc makes liberal use of plenty of other Unix services which do not add to the line counts”. Those sound like “dependencies” to me, and I don’t really see how these are any different from libraries and frameworks. If you look at something like Slack, and remove any lines of code that wasn’t originally written by the Slack team, its footprint would be far smaller.
For example, the “rich text” features (essentially layout, display, and formatting) of suc are provided by the Pygmentize python module (as described in the original article, at least). Those same features in Slack are provided by Electron, so if Pygmentize isn’t counted towards suc line-count then I think we equally need to discount the Electron line-count from the Slack footprint.
The other issue is scaling. I’m sure a massive amount of bloat could be removed from Slack if it only had to serve a few thousand messages to a few hundred users across a few dozen channels. I saw a similar take on a podcast recently. One of the presenters was saying it’s not hard to make a Twitter clone that only has to read / write a handful of messages, to the point that it’s become a developer interview question. The hard part is scaling and profitability, which is so few Twitter competitors sprung up when Twitter was on the rise.
Scalability shouldn’t introduce bloat to this scale, and definitely not on the client side. And even if you cut out Electron from Slack, it’s still a massive amount of code for what it does.
For the client side scalability, I was thinking about things like infinite scrolling rendering, caching, cache invalidation, and generally keeping performance high as the number of channels, contacts, and messages increases.
Electron was just one example I gave. By the same logic I used above, you could discount any third-party code used for encryption, authentication, accessibility, network communications, message parsing, display, and… well pretty much any part of Slack that does a thing using a third party dependency.
Slack is serving a very different market to suc. It would be extremely easy for me to make something that served the same market as suc, though admittedly my version would have been far less elegant. I think there’s a great value in the beauty and minimalism of suc, but I don’t believe there’s any world in which it could keep that beauty and minimalism if it had to serve the same volume, market, and feature cadence as Slack does.
I guess the main point I wanted to make is that this is an apples to oranges comparison presented as an apples to apples comparison.
“generally keeping performance high”
Slack’s performance is not high in any situation. It’s a bloaded garbage, that has 0 original features, except maybe being a bloated garbage.
I should rephrase that as “higher than it would otherwise be”. If Slack operated on a “one file per channel” system like suc does, there would probably be tens of millions of files. The “performance” of any single user trying to read the latest messages from one of those files would be basically zero.
It doesn’t have to be about just Slack either. Any messaging platform with similar scale can be used to make the same points. I use Discord and Teams more often than Slack and, while I wouldn’t call either of them snappy, they’re both perfectly usable.
In terms of scaling, I don’t have the skill to judge this design but it seems like these tools can all be containerized together without much difficulty. That would at least enable easy building/testing and centralized config management with the atomicity of images, assuming trivial overhead as the data and networks scale…
Also, any chance you remember the podcast/episode?
The podcast was the most recent WAN show from Linus Tech Tips. If you find it on YouTube, there should be someone in the comments with a whole load of topic timestamps, so just look for the Meta Threads segment.
The big problem with scaling would be the data. If it’s kept centralised then you have millions of users constantly doing file IO on tens of millions of files. Eventually there’s more file access requests than the server can handle and the whole thing grinds to a halt.
If you distribute it, you also need to replicate the data, which means keeping the files in sync as writes happen to different copies in different locations. That’s going to be extremely difficult with a flat file system holding the data.
There’s also file size to consider. Eventually a channel will have had enough messages sent to it that the file is just too big to be practical. You could archive off part of it, but then you can’t search any of those archived messages.
Thanks, I’ll check it out. And right, I overlooked the whole filesystem approach, duh… seems the ideal way to scale this would require it to treat/use the filesystem like a distributed database with all the complexity that comes with.
Makes me wonder if there’s a sensible way to virtually shim a “normal” database in between layers, instead of reinventing the wheel with some pure-filesystem monstrosity? Of course more work would need to go into the design to address details like chat history with archiving as you point out.
I’m sure there’s someone out there who could come up with some fascinating solutions to the scaling issues. I don’t have enough experience at this kind of scale to know any without falling down a rabbit hole of research, but maybe the future holds a Hackaday article titled “scaling issues suc”
DB2 was the filesystem for AS-400. Nothing new under the sun.
>The design philosophy of Unix is fairly straightforward. Software should do one thing as simply as possible, and do that one thing only.
Hi I am systemD and I am an abomination.
+1 kill it with fire
Strong agree. I know most wont agree with this one, but I also dislike pulseaudio and pipewire. Unless you have some odd use case, alsa works fine 99% of the time. People just want more and more complex crap
systemd and pulse were made by Poettering, and are both hot garbage festering with scope creep and wontfix.
pipewire was made explicitly to address the problem of increasing complexity with pulse/JACK/etc., and screen sharing/video routing in Wayland clients. It really couldn’t be more simple. It even has pulse server emulation to get around the pulseaudio hard dependence in many modern applications, as well as seamless support for JACK, ALSA and GStreamer applications.
Pure ALSA is an abysmal experience if you run more than one DAC, especially if your chain is subject to change or if you want to do more than one thing at a time. Most modern applications aren’t designed to handle pure ALSA. There’s a reason pulse existed in the first place, it’s just awful at what it does.
pipewire solves almost all of pulseaudio’s problems, but still gives you modern desktop flexibility. Since switching to it (on Gentoo) three years ago, I’ve had exactly zero issues out of it. No latency problems, no high CPU usage, no routing issues, no dropouts, no aberrations/distortion, no configuration woes. I can’t say the same for pulse, JACK{,2}, or even the pure ALSA setup on my handrolled Obarun-based Roon endpoints.
I wouldn’t really consider a modern desktop environment to be an “odd use case”. That said, use what best suits your needs.
Have you never seen the 1964 movie “Dr. StrangeDaemon or: How I Learned to Stop Worrying and Love the systemD”?
/g
Why do people hate systemd so much? Yes, everything it does has been done before. But it’s so much nicer to have a uniform interface to all housekeeping tasks rather than juggling an unruly dependency web of syslog, init, cron, NetworkManager, udev, fstab, dnsmasq, ntpd, and who knows how many other Unix-philosophy-respecting tools which all have slightly (or sometimes drastically) different config syntax. If systemd is ‘bloat’ for having these things under one umbrella, then how is the GNU software suite any different?
> Why do people hate systemd so much?
Inflexibility, scope creep, large attack surface (due to scope creep), forced adoption.
Put another way: what happens when something under the umbrella breaks and only systemd contributors can fix it, then log it as a wontfix or “expected behavior”/notabug?
Personally (and as a matter of principle) I won’t use anything that forces me into any particular paradigm. Linux/FOSS is supposed to be about freedom, not forced adherence and appeals to authority. I want to set up and maintain my systems how I please… not how Redhat-turned-Microsoft employees and the “top” distributions tell me I should.
How does one pronounce the app name? Is it ‘suck’ or ‘es-you-cee’?
I’ll guess it’s teh suc
“Software should do one thing as simply as possible, and do that one thing only.”
Boeing hardware engineers’ software standards:
1 Each module shall perform a simple intended function.
2 Shall avoid performing any adverse or benign unintended functions.
3 Shall provide adequate warning in event of failure.
And no module shall be longer than one page of code, of course.
Boeing 737 MAX and F-35 software in compliance?
None of the IM idioms that followed IRC came anywhere close to the standard IRC set.
Yeah, damn them all for refusing to implement netsplits!
To mimic Slack everyone on your team would need to know how to use control characters. That would be difficult for a team with more than two people. Communication tools do not work well If everyone on your team isn’t using them.
One could create a suc GUI app to use as an interface. But then why not just use Mattermost?
I’m sorry, but code that uses ‘while /usr/bin/true; do read read || exit’ instead of ‘while read; do’ is highly suspect.
Church
tool / software bloat is ridiculus.
Puffle, needs druffle, which needs a snuffle account, which depends on the hiffle framework, which needs a piffle account, to share data on miffile, which requires the wiffle helper library, and the fiffle account on the nerfle servers.
blah blah blah, whatever happend to compile, and just work? I should not need an account in 3 different places, 15 different “light weight” frameworks, needing 15gb of libraries, etc.