rename zed binary to zfs-zed

[vitlav]

I suggest renaming the zed binary to zfs-zed, according to the service name. Zed is too short name, conflicted with zed editor.

In many systems /usr/bin/zed is an editor, and /usr/sbin/zed is a zed from zfs.

As I understand it, zed is not for human use in the console anyway.

Renaming to zfs-zed will reduce the chance of accidentally running the command and eliminate file conflicts.

zed-industries/zed#12306
zed-industries/zed#12290

[tonyhutter]

My vote is no -

• ZFS zed predates zed-industries zed (2014 vs 2021).

• It makes it so tab complete for zf<tab> doesn't automatically go to zfs.

• It means our binary name will be different between versions. It's possible the old zed daemon might not get shutdown on an upgrade by the new systemd service file.

• We already name our service file zfs-zed, so naming the binary to zfs-zed would overload that name.

• It's a lot of code updates with no benefit to ZFS

• It dates all our old documentation that references the zed binary.

[lundman]

(zed is a system daemon, should live in */sbin/ and is not expected to be executed by users of the system - whereas the editor should be in $PATH)

[ryao]

(zed is a system daemon, should live in */sbin/ and is not expected to be executed by users of the system - whereas the editor should be in $PATH)

Both */sbin and */bin are in $PATH and */sbin takes precedence over */bin.

That said, my vote is no too, for all of the reasons that @tonyhutter said. There are many system daemons in $PATH that users are not ordinarily supposed to execute, and there are also valid cases when advanced users do want to execute them (like when troubleshooting).

My suggestion to @vitlav is to place a bash alias in ~/.bashrc that replaces zed with whatever he wants it to be.

[lundman]

Ai says:
"No, /sbin is generally not included in the default PATH environment variable for regular users."

I get Linux does whatever it wants.

[ryao]

Ai says: "No, /sbin is generally not included in the default PATH environment variable for regular users."

I get Linux does whatever it wants.

FreeBSD does the same:

https://github.com/freebsd/freebsd-src/blob/9fb60477fe260da2db029baebe63331d0f584a3d/usr.bin/login/login.conf#L30

That said, I vaguely recall this being different on Linux 15 years ago.

[vitlav]

(zed is a system daemon, should live in */sbin/ and is not expected to be executed by users of the system - whereas the editor should be in $PATH)

Both */sbin and */bin are in $PATH and */sbin takes precedence over */bin.

It is possible */bin and */sbin are the same dir:

https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org/thread/OUNAAHIVSYMNXHJ2AMTE5FEPNLSB5RMZ/

[vedranmiletic]

I suggest rename zed binary to zfs-zed, according to service name. Zed is too short name, conflicted with zed editor.

In many systems /usr/bin/sed is an editor, and /usr/sbin/zic is a zed from zfs.

As I understand it, zed is not for human use in the console anyway.

Renaming to zfs-zed will reduce the chance of accidentally running the command and eliminate file conflicts.

zed-industries/zed#12306 zed-industries/zed#12290

Reading from those issues, the editor already uses zeditor as the command name? So, there is no conflict.

[edacval]

It is possible */bin and */sbin are the same dir:

https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org/
thread/OUNAAHIVSYMNXHJ2AMTE5FEPNLSB5RMZ/

Same on Arch Linux:

ls -l /
lrwxrwxrwx   1 root root    7 May  3 22:26 bin -> usr/bin/
drwxr-xr-x   3 root root 4.0K Jan  1  1970 boot/
lrwxrwxrwx   1 root root    7 May  3 22:26 lib -> usr/lib/
lrwxrwxrwx   1 root root    7 May  3 22:26 lib64 -> usr/lib/
drwxr-xr-x   2 root root 4.0K Oct 30  2023 media/
drwxr-xr-x   6 root root 4.0K Jul 15  2021 mnt/
drwxr-xr-x  19 root root 4.0K Feb  4 01:22 opt/
dr-xr-xr-x 516 root root    0 May 13 10:47 proc/
drwxr-x---  17 root root 4.0K May 17 05:27 root/
drwxr-xr-x  30 root root  840 May 13 10:49 run/
lrwxrwxrwx   1 root root    7 May  3 22:26 sbin -> usr/bin/
drwxr-xr-x   7 root root 4.0K Dec 18 00:33 srv/
dr-xr-xr-x  13 root root    0 May 14 00:05 sys/
drwxrwxrwt  99 root root 2.2K May 20 10:00 tmp/
drwxr-xr-x   9 root root 4.0K May 20 06:56 usr/
drwxr-xr-x  12 root root 4.0K May 13 10:47 var/

[snajpa]

There's been a similar issue with zpool_influxdb, which we solved by moving it into the libexec dir: #11224

[ryao]

There's been a similar issue with zpool_influxdb, which we solved by moving it into the libexec dir: #11224

Doing that for zed would violate the Linux FHS:

https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s07.html

[snajpa]

Doing that for zed would violate the Linux FHS:

which part specifically? (I'm not seeing it there)

[snajpa]

So far it looks to me that rules of Fedora/RHEL and co would be OK with this as zed is a program designed to be run by other program, isn't it :)

Debian doesn't ban it but it would be uncommon there...

Arch would rather see the use of /usr/lib/<pkgname> if it must be, it seems.

[ryao]

Doing that for zed would violate the Linux FHS:

which part specifically? (I'm not seeing it there)

This:

/usr/libexec includes internal binaries that are not intended to be executed directly by users or shell scripts.

zed is intended to be run by RC scripts (or the equivalent). Binaries started by RC scripts (or the equivalent) are traditionally in $PATH. To name some from my system that are started at boot by RC scripts: acpid, chronyd, dbus-daemon, dmesg, hostname, hwclock, irqbalance, libvirtd, modprobe, nvidia-persistenced, sshd svscan, sysctl, syslog-ng. There are some exceptions (particularly anything from the systemd tree with the exception of init) and not all of the ones I listed are actual daemons, but daemons and other binaries started at boot being outside of $PATH is the exception rather than the norm.

So far it looks to me that rules of Fedora/RHEL and co would be OK with this as zed is a program designed to be run by other program, isn't it :)

Technically, all binaries are designed to be run by other programs. The init process is intended to be run by the kernel. Everything else is in some way intended to be run by that either directly or indirectly. The init process starts agetty and historically, you would login via it. At which point, agetty will start your login shell. Your login shell will then start any binaries you tell it to start. If we go by "a program designed to be run by other programs", everything would belong in libexec, including the zfs and zpool commands. :/

[ryao]

This conversation might not be worth even having. Zed Industries is venture capital funded:

https://techcrunch.com/2023/03/15/zed-code-editor-raises-10m/

I have worked at startups that are venture capital funded in the past. The investors want rapid growth, so they hand over a lump of money and expect you to spend it to grow a valuable viable business fast. They expect all funds to be spent within a few years (it was 2 in the case of ClusterHQ). Often, the initial "runway" as it is called, is not enough to produce a viable business in even optimistic projections, but the investors will know that and expect you to have made substantial enough progress to merit providing additional rounds of funding to get you there. Their ultimate goal is to get a >50x return on investment and they want an idea that they will get it. This is, of course, unrealistic in all but a few out of around 100 startups, but the times it happens are enough to provide venture capital funds with the money needed to continue investing in new startups. If they do not see what they want, additional funding rounds will not happen. Even if they see a promising company, if there is market uncertainty (and some would say this is the present market environment), a startup in this situation will find raising another round of funding extremely challenging, if not impossible. Then the company will go insolvent, which is what happened to ClusterHQ.

Zed Industries raised round A funding in early 2023. They should need to raise round B funding soon to stay in business. If they do not, there will be no Zed Industries. Changing the location or name of an important daemon for a company that might not be around in a year is not a great idea.