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]

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]

[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]