From mboxrd@z Thu Jan 1 00:00:00 1970 From: ag4ve.us@gmail.com (shawn wilson) Date: Fri, 24 Mar 2017 04:06:29 -0400 Subject: [TUHS] Were all of you.. Hippies? In-Reply-To: <20170324073748.GA39889@wopr> References: <20170320214858.TIJoR%steffen@sdaoden.eu> <009301d2a1c9$cb604c70$6220e550$@ronnatalie.com> <20170321202839.GG21805@naleco.com> <20170324001832.GA13511@naleco.com> <20170324002754.GW23802@mcvoy.com> <20170324073748.GA39889@wopr> Message-ID: On Fri, Mar 24, 2017 at 3:37 AM, Kurt H Maier wrote: > On Fri, Mar 24, 2017 at 07:15:13AM +0000, shawn wilson wrote: >> >> Everything is still a file. > > Except for your network, of course -- that might have a file interface > available... provided by your shell. Because of course /dev/tcp should > be a shell feature. Why would anyone put that in the kernel? > I actually have strong opinions about this (read: disagreements). Your shell shouldn't know about connect() - I guess allowing writing to /dev/eth0 would work for me. But in bash, IIRC that damn ghost file thing is like half of the files in source and it helps nothing. Maybe if the point was to allow some remote shell (like X does) I could see it (but than I'd scream about the security implications about something like that). And I'll say again - why? You want a socket - nc, ncat, socat - pick one - don't abuse your shell. > Linux (and the wider later-unixlike world) is full of these bizarre > little > quirks -- due to the earlier-mentioned practicality. At first it was > people scratching their own itches, then it switched over to people > scratching corporate itches. > I've got mixed feelings about this - while I like being able to install a Fedora or Debian on a box and it generally just work (except for things like raid controllers, IPMI, and the like) and remember the days of Slackware where it took a week just to get to a point where you were ~happy with an install. I do kinda see how this went a bit sideways and wish someone had put some thought into where things went (memory/calls and files). > Linux has around 400 system calls, and still supports just about ever > (userspace-exposed) syscall it has ever had. This is why it needs a > thousand little binary shims to get stuff done, and the push for systemd > was the pendulum swinging back the other direction. Since > open/read/write/close isn't enough, we'll build a layer to handle all > the weirdness, and now all you need is dbus... > No one wants to see their pet project die :) No one cares when it's userspace, but it adds up in kernel space.