MIME-Version: 1.0
From: Askar Safin <safinaskar@gmail.com>
Date: Fri, 18 Nov 2022 06:51:12 +0300
Message-ID: <CAPnZJGBejeA+9APimVY6+HH=fWZJfW=QXJaOEK-JhhESRP+cSg@mail.gmail.com>
Subject: Re: In praise of Plan 9: Plan 9 doesn't have true "mv"!
To: ~sircmpwn/public-inbox@lists.sr.ht
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi. This letter is mostly not for Drew himself, but for everybody
else. I hope that Drew's readers will read this mail and will know how
bad Plan 9 actually is.

Plan 9 is not a good OS by modern standards (UNIX-like systems are
not, either). For example, let's consider "mv" util. Here is its Plan
9 (more precisely: 9front) sources:
http://git.9front.org/plan9front/plan9front/30c5296f32b87d83529d77273272689=
1e1261c9c/sys/src/cmd/mv.c/f.html
. As you can see by carefully reading this source, "mv" always
unconditionally COPIES file data (as opposed to Linux: Linux and all
sane OS move files without copying when on the same file system)! I
once asked somewhere (as well as I remember in IRC) why Plan 9 doesn't
have a true mv.

As well as I remember I got this answer: this is because the 9P
protocol (core file protocol in Plan 9) doesn't have move operation.
It doesn't have this operation because of some fundamental reason
related to the beautiful Plan 9 file model. I think this is a very bad
design.

If Plan 9 folks always copy files instead of moving, what can be said
about all other performance-oriented features? I'm nearly sure that
every time Plan 9 authors have a chance to add some
performance-oriented feature, they simply deny it arguing "this will
destroy our nice abstractions". (But if you cannot add
performance-oriented features because of abstractions, it means
something is wrong with your abstractions.)

Now let me move to the next point. Here is a quote from Drew's article:
> Plan 9 is much more Unix in its approach: you open /net/tcp/clone to rese=
rve a connection, and read the connection ID from it. Then you open /net/tc=
p/n/ctl and write =E2=80=9Cconnect 127.0.0.1!80=E2=80=9D to it, where =E2=
=80=9Cn=E2=80=9D is that connection ID. Now you can open /net/tcp/n/data an=
d that file is a full-duplex stream.

Aaaaaaaah! This is a very bad interface. It is slow, it requires a lot
of syscalls. It requires producing text and then parsing this text at
other side. (And parsing is always error-prone.) This interface
requires user to write "magic" text to "magic" files instead of simply
issuing apropriate syscall. In this video:
https://www.youtube.com/watch?v=3D9-IWMbJXoLM Rice describes why such
magic files are bad (from 0:00 to 11:00).

Then Drew says:
> No magic syscalls, and you can trivially implement it in a shell script.

????? So Drew thinks that the ability to do TCP from shell script is
somehow a feature? Shell script is one of the worst programming
languages, shell scripts should not be used at all.

--=20
Askar Safin