Ubuntu Slaughters Kittens | BSD Now 103

[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

in “Maintaining 65k open connections in a single Ruby process” · View on HN

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

in “LinuxBoot: Linux as Firmware” · View on HN

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

in “Epoll is fundamentally broken” · View on HN

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]

in “Microsoft and Canonical partner to bring Ubuntu to Windows 10” · View on HN

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]

in “No POST after rm -rf /” · View on HN

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

in “Linux 4.5-rc5: efivarfs fixed to avoid “rm -rf /” bricking UEFI” · View on HN