Re: [TUHS] "What UNIX Cost Us"

[Warner Losh <imp@bsdimp.com>]

[-- Attachment #1: Type: text/plain, Size: 4103 bytes --]

Benno's talks (systemd and this one) weren't wrong. Systemd *is* a dumpster
fire. It has a lot of cool ideas, but is coded by someone that has poor
listening skills and is more stubborn than he's technically competent. It's
had a crapton of severe security bugs in it. It's given us abominations
like eth4156 as a NIC name. It doesn't like it when you & a job and log out
for Pete's sake. It's a total mess that breaks everything to try to push
the state of the art. Beno's talk on it may have been a little over the
top, but he's not wrong about much of his criticism. Systemd has swung too
far from the do one thing and do it well philosophy, admittedly in ways
that are ham-fisted and don't necessarily mean that it's philosophically
wrong, that it shows at least some of thee wisdom of simplicity.

Benno's Unix talk is similar. He's not wrong. The everything is a file
paradigm has issues.

On Sun, Jan 19, 2020 at 3:47 AM Tyler Adams <coppero1237@gmail.com> wrote:

> His example of the USB driver was pretty silly. The unix code even
> *looked* cleaner and straightforward compared to the convoluted
> windows/mac messes, but he's mad because he had to figure out a *filepath*.
> What!?
>

Figure a  dozen file paths out, cat the right thing to them so other files
show up and  then you can  do the same thing again? That's  not a sane
interface. Everything isn't a file.  We've known this since the 70's. The
first NCP/TCP stacks were terrible in this way. You opened /dev/net/london.
And while that sounds cool, it means you have to have some kind of name
lookup in kernel which isn't a directory lookup. You either need a userland
daemon to do  the work and sleep, or you need to do crazy things like that
in the kernel. And there was no really good way to do what we do with
select, poll, kqueue or the like. And trying to do really high end, high
data rate stuff with read/write is inefficient.

At Netflix we use sendfile for our stuff. It's one of the least
unixy things in the kernel. It reads from a file, then TLS encrypts the
file and sends it out the socket. This means state has to be carefully
managed with some setup in userland before the handoff. The other non-unixy
thing is that it's all non blocking. sendfile asks for a set of pages from
a file. When they are ready, it gets a callback to schedule encryption, and
when that fires it's scheduled to the NIC for transmission and either
retransmission or freeing up depending on the ACKs that come back. At
~190Gbps, this isn't something one can do with the normal Unix interfaces,
which was the point of his talk. He's not wrong, but his examples could use
some work.

The real world is messy, and often requires complexity. Going too simple
for simplicity's sake is just as bad as going too complicated for
complexity's sake. A proper balance is needed. And he's not wrong to make
that point.

Warner

P.S. complaining about Benno's involvement in cleaning up FreeBSD's fortune
in response to his talk is lame and puerile. Totally off topic and typical
of the stupid and ill-informed attacks that he attracted around the code of
conduct stuff by jerks that had no stake in the FreeeBSD community, but
instead wanted to fight for their absolute right to be self-absorbed jerks
without consequences. It totally burned him out, and the FreeBSD community
lost a contributing member because of the grief he got. It's unbecoming to
see it on this list.


>  Tyler
>
>
> On Sun, Jan 19, 2020 at 12:37 PM Vincenzo Nicosia <katolaz@freaknet.org>
> wrote:
>
>> On Sat, Jan 18, 2020 at 11:27:39AM -0800, Rich Morin wrote:
>> > FWIW, I found this talk to be quite amusing and interesting.
>> >
>> > "What UNIX Cost Us" - Benno Rice (LCA 2020)
>> > https://www.youtube.com/watch?v=9-IWMbJXoLM
>> >
>>
>> ...which is along the same lines of the talk the same guy gave about
>> systemd and why everybody should like it. The message is simple: we
>> just want to run our shiny MacBooks and we don't understand Unix
>> anyway, so we'd better get rid of it and move on.
>>
>> A flawed analysis that obviously leads to flawed conclusions.
>>
>>

[-- Attachment #2: Type: text/html, Size: 5404 bytes --]