Program names and "pollution" [LWN.net]

Program names and "pollution"

Posted Apr 2, 2019 20:26 UTC (Tue) by ntnn (guest, #109693) [Link] (1 responses)

Yeah, that was my first thought as well.

Also it's not hard to rename commands. Rename them in one major version, provide the old ones as symbolic links and display warnings when they're called by their old names that they're going to be unavailable in the next version.
Once that one rolls around remove the symlinks and you're done.

Will it break some scripts somewhere? Yeah. But then it's the fault of the admins running it for upgrading a major version without checking the changelog.

Program names and "pollution"

Posted Apr 2, 2019 20:29 UTC (Tue) by ntnn (guest, #109693) [Link]

Hadn't finished reading the article before I got to the mention that Alvaro Herrera suggested to do exactly that.

Program names and "pollution"

Posted Apr 3, 2019 8:18 UTC (Wed) by kandreas (guest, #131050) [Link] (9 responses)

The PostgreSQL project is fine with doing the work. The concern is that we will break tons of end users' scripts and pissing them off. I am one of those arguing in favor of fixing this but I know fixing it will break a ton of third party tools and in house scripts at various companies when we in 3-5 years time pull the plug and remove the legacy aliases. Even with a long deprecation cycle with warnings some people will not update their scripts.

Program names and "pollution"

Posted Apr 3, 2019 10:15 UTC (Wed) by lamawithonel (subscriber, #86149) [Link] (4 responses)

Maybe you need more phases than only Deprecation and Removal. The following would be a lot more work, no doubt, but it would give users a lot more options and opportunity to fix things.

1: Move existing commands to pg_* and create symlinks.
1a: (optional) Create a central binary with sub-commands, à la `git` or `systemctl`, and move all the pg_* commands under that. Replace symlinks with shim binaries.
2: Start printing a warning if commands are called by their legacy names, but allowi users to silence the warnings with an option flag.
3: Create a build path to build only the symlinks/shims, and a non-default way to build without them. This gives packagers an easy way to package them separately, and users a way to test without them. It also gives packagers some control over how and when they remove the symlinks/shims.
4: Make deprecation warning silence flags NOOP.
5: Inspired by rfunk's comment, move the symlinks/shims out of $PATH, to something like /usr/share/postgres/bin, and declare them unsupported. Inform users that they can add the new directory to their $PATH if they really need them for some reason, but that you won't accept bug reports against them. Maintain this for at least another major release, possibly several more.
6: Rejoice when our AI overloads remove all the symlinks/shims.

Program names and "pollution"

Posted Apr 3, 2019 10:24 UTC (Wed) by lamawithonel (subscriber, #86149) [Link]

err... 6 should actually be "invert the build option so the symlinks/shims are not built by default," 7 would be "Rejoice when our AI overlords remove all the code to build and test symlinks/shims."

Program names and "pollution"

Posted Apr 3, 2019 15:19 UTC (Wed) by kh (guest, #19413) [Link] (1 responses)

Why not create a separate package postgresql-legacy-cmds to put all the deprecated commands in. That way if some end user has a bunch of scripts they don't want to update, and they ignore all the deprecation warnings for a few years, when the commands are actually deprecated, (and this new package is no longer a dependency) all they will need to do with newer systems to fix their scripts is a quick apt-get postgresql-legacy-cmds or equivalent and they can continue to use all their old scripts, but others will not be bothered. Maybe this is already implied or suggested and I missed it.

Program names and "pollution"

Posted Apr 4, 2019 13:25 UTC (Thu) by lamawithonel (subscriber, #86149) [Link]

That's the point of #3. The first-line build system is something the developers control, and doing it there makes sure everyone gets it, be that packagers in the project, distro packagers, or users who compile it themselves. Also, in my experience, a lot of people won't even consider things like removing part of the build, so giving them a way to do it, even if they don't end up using the way provided, helps jolt imagination.

Program names and "pollution"

Posted Apr 3, 2019 17:19 UTC (Wed) by rotty (guest, #14630) [Link]

Regarding step 3 (creating a separate build path to build only shims/symlinks to aid packaging), I'd like to add that this seems likely unnecessary for distributions which have a binary/source package separation, such as Debian. Whether to include specific files, and in what package binary package to include them in, is already up to the maintainer. In the case of Debian, the `debian/*.install` files specify exactly that.

This build system feature, though, would probably helpful on source-based systems, though I'm not familiar with those.

Program names and "pollution"

Posted Apr 7, 2019 0:13 UTC (Sun) by rossmohax (guest, #71829) [Link] (3 responses)

deprecate gracefully by introducing startup delay of 10 seconds every major release

Program names and "pollution"

Posted Apr 9, 2019 1:40 UTC (Tue) by k8to (guest, #15413) [Link] (2 responses)

This is an entertaining idea. My practical perspective is as a user I would not be entertained to debug this.

Program names and "pollution"

Posted Apr 9, 2019 15:16 UTC (Tue) by nix (subscriber, #2304) [Link] (1 responses)

Hm, you could deprecate gracefully by producing a non-interruptible animation of a steam locomotive every time someone types the old names? :P :P

Program names and "pollution"

Posted Apr 9, 2019 23:35 UTC (Tue) by karkhaz (subscriber, #99844) [Link]

You joke, but I'm pretty sure that Android did something similar to the delay thing...but I don't remember the details, maybe somebody else can furnish them. My recollection is that they wanted to force application developers to link against a new incompatible version of some library (maybe libc/bionic?). So they added a startup delay (I guess to _start() or something) and increased the delay every few weeks until the users noticed.

Program names and "pollution"

Posted Apr 7, 2019 23:07 UTC (Sun) by jschrod (subscriber, #1646) [Link] (5 responses)

YES!!!

And while we're at it:
- Rename creat() to create().
- Clean up that awful abbreviation "pwd" to
have something to do with passwords instead of meaning "print working directory", as any newbie would expect.

On a serious note, it's not always as practical to change established namings even if it would be sensible.

Cheers, Joachim

PS: These two changes/gripes were mentioned by Dennis Ritchie at a conference dinner where I had the occasion to be at the same table. So please don't blame me for bringing them up. :-) :-)

Program names and "pollution"

Posted Apr 8, 2019 9:01 UTC (Mon) by anselm (subscriber, #2796) [Link] (4 responses)

These two changes/gripes were mentioned by Dennis Ritchie

According to legend, Ken Thompson was once asked what he would do differently if he were to redo Unix from scratch. His answer was “I'd spell ‘create()’ with an ‘e’ at the end.”

OTOH, if your main means of interaction with the computer is a 110-baud teletypewriter, you may be forgiven for wanting to make every character count. In that situation, using “?” as an error message starts making a lot of sense.

Program names and "pollution"

Posted Apr 11, 2019 9:14 UTC (Thu) by mgedmin (subscriber, #34497) [Link] (3 responses)

Wasn't it a linker limitation originally? 6 characters per name, plus C name mangling prepended an underscore for some reason, so _creat was the longest you could have at the linker level.

Program names and "pollution"

Posted Apr 11, 2019 19:42 UTC (Thu) by jengelh (guest, #33263) [Link]

>Wasn't it a linker limitation originally? 6 characters per name,

There is the "localtime" call in V7 (at least whatever copy I could grab off github), which is way above 6 characters.

Program names and "pollution"

Posted Apr 11, 2019 19:51 UTC (Thu) by jengelh (guest, #33263) [Link] (1 responses)

>Wasn't it a linker limitation originally? 6 characters per name,

And as for V1, there is the "putchar" function.

Program names and "pollution"

Posted Apr 12, 2019 1:08 UTC (Fri) by neilbrown (subscriber, #359) [Link]

> And as for V1, there is the "putchar" function.

Was there?? I thought "putchar" was a macro for fputc(c, stdout), but I haven't checked V1. Rules for macro names would be different from those for linker symbols.