Ubuntu Slaughters Kittens | BSD Now 103

Reminds me of Cantrill, more so his story when they completely bricked a machine of a fellow worker once and then took a close look at the standard[1]. # rm -rf / Among other things, it will delete the current directory. In the standard it does not say what to delete first, In their implementation it will try to remove the current directory first -> undefined behaviour -> it fails. The logic behind it: When is it really your goal to delete your entire machine, mostly never, you don't type it out by accident, but shell scripts with unset variables might do it. And regarding Poettering's response[2] (not trying to start a fight): It's Poettering, what do you expect? You can hate or love systemd, but part of why people hate it is his intellectual arrogance in everything he does. [1] He tells the story somewhere in here this video (quite entertaining) [2] link

For the few use cases where a system admin wants to "rm -rf /", there are hundreds of bad scripts that can screw up a system. I believe Solaris did the right thing and made it not work. this video

Exciting stuff! This is (very?) similar what with LX branded zones in SmartOS[1][2] -- and, as I've said before[3] -- we want as many other systems as possible take this approach. That said, we also know how long a haul this is, and how detail-intensive it is. So I've got a bunch of questions. ;) First, is the source available? Second, how much of the One Hundred Language Quine Relay[4] runs successfully? (For us, running that sucker to completion was an important early milestone.) Assuming that runs, my next questions are all common apps/programs that we knew to be especially thorny for one reason or another: Go, strace, tcpdump, systemd, etc. Anyway, it's great to see the SmartOS approach so broadly validated by Microsoft -- and hope that they both finish the job and open source it all! [1] link [2] link [3] this video [4] link

The linked interview with Bryan Cantrill gives a good explanation of why it's broken: a straightforward implementation behaves in a way you never want, with bizarre behavior where the kernel can wake up a thread with an accept() on a fd that has already been closed. linux should just have adopted kqueue or an IOCP model instead. this video

this video - watch it to the end. How long "people have been doing it" has nothing to do with the quality, it's a fallacy. They can't code if they can't even get the basics like polling or startup / shutdown correctly.

link While a best effort has been made to mimic the Linux semantics, there are some semantics that are too peculiar or ill-conceived to merit accommodation. In particular, the Linux epoll facility will -- by design -- continue to generate events for closed file descriptors where/when the underlying file description remains open. For example, if one were to fork(2) and subsequently close an actively epoll'd file descriptor in the parent, any events generated in the child on the implicitly duplicated file descriptor will continue to be delivered to the parent -- despite the fact that the parent itself no longer has any notion of the file description! This epoll facility refuses to honor these semantics; closing the EPOLL_CTL_ADD'd file descriptor will always result in no further events being generated for that event description. Brian Cantrill on epoll this video

Well, not a question. POSIX and Linux are not the same. There is no epoll in POSIX, it's a Linux addition. The BSDs have kqueue which according to some people is actually better [cf. this video ]. But kqueue isn't POSIX either. Only poll() and select() are...

He mentions Bryan Cantrill in there and I can’t resist posting his famous epoll/kqueue rant: this video I know this is related but maybe someone smarter than me can explain how closely it relates (or doesn’t) to this issue which seems more general (iirc Cantrill was talking about fs events not child processes generally)