Re: [TUHS] UNIX of choice these days?

Larry McVoy: Kurt H Maier: The usual rationale presented is that someone can exhaust the fd table and then you can't get anything done. Instead of fixing that problem, the popular approach is to add more syscalls, like with getrandom(2). ==== Funny that that rationale isn't extended to its logical conclusion: get rid of open and creat. Then nobody needs to worry about running out of file descriptors ever! I too am saddened to see such a retrograde step, but perhaps I'm biased. When I arrived in 1127, the kernel had /proc but still had ptrace as well. Why? Because no one was brave enough to wade into sdb and adb. After a couple of years, I felt brave enough, so I did it. Once the revised sdb and adb had propagated to all our systems, I removed the syscall. I celebrated by physically removing ptrace(2) from the Eighth Edition manual in the UNIX room: the manual entry comprised two facing pages, which I glued together. I can sympathize with FreeBSD excuse someone cited elsewhere, that nobody used the code so it should go--I'm always in favour of improving programs by chopping sutff out--but I think the decision here was backwards. The proper answer would have been to teach ps et al to use /proc, not to invent a new complex of system calls. I dislike how Linux has tossed information about processes and other system-related data into the same namespace (and now that there is /sys as well as /proc, I wonder whether it's time to divorce them, or even to move /proc into /sys/proc), but the general direction of moving things into the file system makes sense. I have some qualms about adding more and more code to the kernel that just does string processing (making the kernel bigger and more complicated, and widening the attack surface for bad guys), though; maybe most of that stuff belongs not in the OS proper but in a user-mode program that reads /dev/mem and presents as a file system. Norman Wilson Toronto ON