openzfs
rename zed binary to zfs-zed
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.
https://github.com/zed-industries/zed/issues/12306 https://github.com/zed-industries/zed/issues/12290
My vote is no -
-
ZFS
zedpredates zed-industrieszed(2014 vs 2021). -
It makes it so tab complete for
zf<tab>doesn't automatically go tozfs. -
It means our binary name will be different between versions. It's possible the old
zeddaemon 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 tozfs-zedwould overload that name. -
It's a lot of code updates with no benefit to ZFS
-
It dates all our old documentation that references the
zedbinary.
(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)
(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.
Ai says: "No, /sbin is generally not included in the default PATH environment variable for regular users."
I get Linux does whatever it wants.
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.
(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/[email protected]/thread/OUNAAHIVSYMNXHJ2AMTE5FEPNLSB5RMZ/
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.
Reading from those issues, the editor already uses zeditor as the command name? So, there is no conflict.
It is possible */bin and */sbin are the same dir:
https://lists.fedoraproject.org/archives/list/[email protected]/ 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/
There's been a similar issue with zpool_influxdb, which we solved by moving it into the libexec dir: https://github.com/openzfs/zfs/pull/11224
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
Doing that for zed would violate the Linux FHS:
which part specifically? (I'm not seeing it there)
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.
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. :/
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.
This conversation might not be worth even having. Zed Industries is venture capital funded
To me this isn't about the company, but the intersection of that company's customers (unimportant to me) and our users (who I care about), I would just like to think we're doing the best we can for our users, even if they're choosing to use a VC-backed editor :) I already think our users on desktop are brave, having to put up with all the bugs lately :D
If there's some suffering due to zed naming collision, I don't know, don't have any real preferences, I just think that due to ZED being a daemon and so its executable location being mostly important to the init system, we could move the binary. Though I'm less of a fan of the rename step, zfs-zed seems to strike the funny chords of led-diode, lcd-display, etc. :D
To me this isn't about the company, but the intersection of that company's customers (unimportant to me) and our users (who I care about), I would just like to think we're doing the best we can for our users, even if they're choosing to use a VC-backed editor :)
I understand this sentiment very well, as I often share it. However, I look at this and I imagine the change causing a headache for a number of system administrators, who will say "are you kidding me" when hearing the change was to make things easier for users of a text editor.
That said, changing this in HEAD would not change things in existing distributions. In the case of Ubuntu, it could be years before a change actually would make a difference to users of the zed editor (as people will likely run 24.04 until 2029), since we are unlikely to backport a location change into a stable release branch. Doing that conflict with the goals of downstream distributions that follow a stable release model to limit potentially breaking changes to major releases and would likely cause problems that the policies of limiting breaking changes to major releases is meant to avoid. If Zed Industries becomes insolvent before then, there would likely have been no point to the churn.
I really would prefer to leave this alone, mainly because changing it to try to please some users is undoubtedly going to cause a headache for others. For example, if someone is running zed via daemontools (because systemd will give up after too many restart attempts), moving zed will break that script.
Umm, after reading a bit through what's been happening in the editor's repo, well, they don't seem to have a problem with renaming to zed-editor, solving the conflict. It's just that maybe the rename hasn't been done completely yet - https://github.com/zed-industries/zed/issues/12290 https://github.com/zed-industries/zed/pull/12622 https://github.com/zed-industries/zed/pull/12951
So just from that I think no action needs to be taken in OpenZFS
Umm, after reading a bit through what's been happening in the editor's repo, well, they don't seem to have a problem with renaming to
zed-editor, solving the conflict. It's just that maybe the rename hasn't been done completely yet - zed-industries/zed#12290 zed-industries/zed#12622 zed-industries/zed#12951So just from that I think no action needs to be taken in OpenZFS
That was done last year since they have a weekly release cycle. This issue appears to be a request from one of zed-editor's users for us to release the name zed for reuse by zed industries so that they can rename zed-editor to zed to match what they do on MacOS.
Yeah, I appreciate the ask, but this is what it is.
If we're all operating in the same namespace, clashes are inevitable. User aliases and wrapper scripts exist, and downstream packagers routinely rename or move things to avoid conflicts in their own repositories.
Renaming it here for anything other than our own reasons is just going to be add confusion, for our direct users who wonder who moved their cheese, and for our downstream packagers who have to update their packaging and possoble un-rename it.
- It makes it so tab complete for
zf<tab>doesn't automatically go tozfs.
Tab complete still works to zfs with things named zfs-something existing, zf<tab> fails when things like zfgrep or zforce exist. At least on Linux.
zfs-zedseems to strike the funny chords ofled-diode,lcd-display, etc. :D
Would zfs-eventd not be a better, more descriptive name, in these days of systemd?
I'm against renaming for the sake of the editor, which will most likely not be installed as root.
Privileged and unprivileged user profiles can set different paths. It may be left to the user, who decides to install two optional binaries of the same name into different directories which are both added to the path, in which order to put them.
On my local system everything is as it should be:
$ sh -c 'type zed'
zed is /home/yala/.local/bin/zed
$ sudo sh -c 'type zed'
zed is /usr/sbin/zed
Am I missing something?
The systemd unit will also call zed by its absolute path in the Exec statement, why this is maybe a non-issue? Supposing to close here.
