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

Simple Unix Chat

the-dam.org

Post reply on HN
Print view View original

161–170 of 175 posts

Re: Simple Unix Chat

#161

Post by pgtan »

linschn wrote: post #152
pgtan wrote: post #113

Earlier quoted context omitted.

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

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…

for builtin security see for example https://unix.stackexchange.com/questions/102746/how-to-invok...

Re: Simple Unix Chat

#162

Post by boffinAudio »

themoonisachees wrote: post #127
linschn wrote: post #109

Earlier quoted context omitted.

I couldn't make talk or wall work on a modern linux system. That's a shame.

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.

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

Re: Simple Unix Chat

#163

Post by zokier »

throwawaymobule wrote: post #159
zokier wrote: post #79

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

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.

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.

Re: Simple Unix Chat

#164

Post by siilikuin »

throwawaymobule wrote: post #157
themoonisachees wrote: post #130

Earlier quoted context omitted.

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.

Doing MFA for ssh like that would satisfy some compliance issues, wherever that matters. Probably key+pass.

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

Re: Simple Unix Chat

#165

Post by palata »

pjlegato wrote: post #128
numpad0 wrote: post #13

I think the intuition would be that if a determined "core" feature set of something is so easily and trivially reproduced, then it's not the core/source of its value. Which makes me wonder: Just how much of UI development had software engineering had consumed and automated since 1980s, or is it still in the realm of pure human art?

This is correct. The core value-add of e.g. Slack is not actually "transmit messages between authenticated users." There were dozens of other applications, both commercial and open source, that already did exactly that when Slack came out and killed them all off. The core value proposition of Slack is next-level beyond that: it adds a visually appealing, highly intuitive UI/UX that almost anyone can sit down and imme…

> it adds a visually appealing, highly intuitive UI/UX that almost anyone can sit down and immediately use

And yet, there were dozens of other applications doing exactly that (Slack is a list of channels on the left, and the text of the channel in the center).

Re: Simple Unix Chat

#166

Post by palata »

Aeolun wrote: post #90

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.

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?

Re: Simple Unix Chat

#168

Post by memetomancer »

jcynix wrote: post #138
bandrami wrote: post #137

Earlier quoted context omitted.

You said files, not inodes. Those are two files sharing one inode. If you want to count inodes, specify that in the question.

I'm not the one who posed the question. And: file, filename, inode, ...? What's what and what's exactly to be counted?

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.

Re: Simple Unix Chat

#169

Post by esbeeb »

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/

Re: Simple Unix Chat

#170

Post by Fnoord »

liveoneggs wrote: post #155

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

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

Post reply on HN