On Thu, Oct 10, 2019 at 11:11 PM Stephen Reay <step...@koalephant.com> wrote:
> > > > On 11 Oct 2019, at 12:40, Walter Parker <walt...@gmail.com> wrote: > > > > G > > > > On Thu, Oct 10, 2019 at 10:10 PM Stephen Reay <step...@koalephant.com> > > wrote: > > > >> > >> > >>> On 11 Oct 2019, at 02:59, Walter Parker <walt...@gmail.com> wrote: > >>> > >>> On Thu, Oct 10, 2019 at 10:36 AM Chase Peeler <chasepee...@gmail.com> > >> wrote: > >>> > >>>> > >>>> > >>>> On Thu, Oct 10, 2019 at 1:30 PM Walter Parker <walt...@gmail.com> > >> wrote: > >>>> > >>>>>> > >>>>>> > >>>>>> No. The compromise is funding a ferry system. Or laying Internet > >> between > >>>>>> them. Or a passenger pigeon mail route. > >>>>>> > >>>>>> Sometimes compromise requires deep discussion about the motivations > >> for > >>>>>> each side and coming to a lateral, mutually acceptable, solution. > >>>>>> > >>>>>> But we'd rather not discuss motivations and just bicker about the > >>>>> surface > >>>>>> results. I.e., argue the X, rather than the Y, of these little XY > >>>>> problems > >>>>>> we're solving. > >>>>>> > >>>>>> > >>>>>> > >>>>> Build a ferry system is alternative to building bridge. I can see > that > >> as > >>>>> a > >>>>> compromise, I can also see that as a separate project created to > serve > >>>>> demand after the the bridge project is rejected. Where a ferry system > >> is > >>>>> started because there is still demand for transit, just not enough > >> demand > >>>>> to pay for a bridge. > >>>>> > >>>>> With respect to the backtick proposal, what is the "ferry" project? > Do > >> we > >>>>> have to come up with one before we can cancel the "bridge" project or > >> can > >>>>> we cancel the "bridge" project on its own merits and then discuss a > >> future > >>>>> project that solves the actual underlying problem? > >>>>> > >>>>> "Ferry" projects might be: more/better training on PHP, better > >>>>> documentation so that the backtick is no longer an "obscure" feature > to > >>>>> those that don't have a shell/Unix/Perl background, tooling to warn > >> people > >>>>> when they misuse this feature. > >>>>> > >>>>> > >>>>> > >>>> To the side that says "There is absolutely no reason we need to go to, > >> or > >>>> communicate with, the island in the first place," a ferry project > isn't > >> a > >>>> compromise. The position of the "anti-bridge" builders isn't because > >> they > >>>> are against building bridges - it's because they are against spending > >>>> resources on attempts to get to the island in the first place. The > other > >>>> side might have valid arguments on why we need to get to the island, > >> but, > >>>> just proposing different ways to get there isn't compromising with the > >> side > >>>> that doesn't want to go there. > >>>> > >>> > >>> I think you may have just created a strawman for the anti-bridge > >> position. > >>> There are famous anti-bridge cases, like the Bridge to Nowhere in > Alaska > >>> (if you don't remember, there was an island in Alaska that had 50 > people > >>> and Senator Stevens wanted to replace the existing ferry system with a > >> $398 > >>> million bridge). People complained about the bridge not because they > >> wanted > >>> the islanders to to isolated, but because it was poor use of money when > >>> there where bigger and more urgent problems. > >>> > >>> To bring this back to PHP, is the backtick really a urgent problem of > >>> enough magnitude that it justifies the cost of a BC break in unknown > >> amount > >>> of PHP code that has been functional for years. If this proposal passes > >>> (and the follow up to remove it which I'm certain will be proposed), > then > >>> this is one that leaves people on the island as they will either be > stuck > >>> on an old version of PHP or have to pay to update the code. This pushes > >> the > >>> costs on them to solve a an existing issue that 20 years after it was > >>> created and is now an issue because a new generation of coders, unaware > >> of > >>> history, find the existing syntax not to there taste/a poor design. Why > >> are > >>> we giving priority to people that haven't taken the time to educate > >>> themselves over people that did and used programming style that used to > >>> common? > >>> > >>> > >>>> > >>>> > >>>>> Walter > >>>>> > >>>>> -- > >>>>> The greatest dangers to liberty lurk in insidious encroachment by men > >> of > >>>>> zeal, well-meaning but without understanding. -- Justice Louis D. > >>>>> Brandeis > >>>>> > >>>> > >>>> > >>>> -- > >>>> Chase Peeler > >>>> chasepee...@gmail.com > >>>> > >>> > >>> > >>> -- > >>> The greatest dangers to liberty lurk in insidious encroachment by men > of > >>> zeal, well-meaning but without understanding. -- Justice Louis D. > >> Brandeis > >> > >> > >> Hi Walter, > >> > >> The RFC at the centre of this ridiculous string of analogies is about > one > >> thing: deprecate (i.e. show a deprecation message) about the backtick > >> operator. > >> > >> The RFC specifically doesn’t lay out a timeline for actual removal, it > >> doesn’t even hint at “well it’ll just be automatically removed”. > >> > > I find disingenuous, the author of the RFC has said more than once that > > removal is a goal of his. I think it is perfectly fair to look ahead and > > view the process as a whole (the end goal). When walking to the edge of a > > cliff, we don’t have to wait until we get to the edge to understand that > > waking off the cliff is a mistake. > > > > > It’s not disingenuous at all. Yes, the long-term goal is to remove the > backtick operator. That isn’t what this RFC is about though. This RFC is > about marking it as deprecated - indicating to users that it is *likely* to > be removed at some future date. > > > > > >> So this RFC breaks *nothing*. > >> > >> Yes, it does lead to the situation where it’s likely that a followup RFC > >> will propose removing the (then) deprecated feature - perhaps 9.0, > perhaps > >> it’ll be discussed pre-9.0, and held off until 10.0? But any such change > >> will then require *another* vote, with another round of discussions and > no > >> doubt ridiculous analogies. > >> > >> And at that time, after several years of warnings about deprecation, > >> Nikita or someone else will likely pop up with some analysis of > projects to > >> show usage *at the time*. > >> > >> If the only reason to keep a dangerous operator is “well a small subset > of > >> people use it”, marking it as *deprecated* is how you signal to those > >> people that the feature will likely be removed in a future version. > >> > >> > > Now you are assuming the conclusion. Once of the main debates here is if > > the backtick is a dangerous thing. That has still to to be proven to many > > people. > > > > If you don’t understand how exposing shell execution via a single > character operator is dangerous, I can’t help you. > If you can’t explain it , why do you expect others to support you. Remember what Feynman said, if you can’t explain it, you don’t really understand it. Really, if you use backtick as a regular quote, the odds of breaking anything are low. Even lower when you use code review, analysis tools and a QA team worth a damn. From a security point of view any shell exec is a security risk. The number of characters required to execute it is hardly important. I suggest to re-examine your threat modules. I still have not seen anything on this thread that amounts more than I feel it would make us safer. > > > > >> The argument about “shell style scripts” that are on a server which > >> constantly gets updated to the newest release but never gets any > >> maintenance to the scripts is a ridiculous fantasy. > >> > >> There is zero chance someone is dist-upgrading from one release to the > >> next through enough versions that they get to one where the > distro-provided > >> php is such that backticks are actually removed, and yet the only thing > >> that breaks is the backticks. > >> > >> > >> > >> To be honest, what I really care about is people not breaking the PHP > > applications that I’m currently using (Roundcube, phpmyadmin, Wordpress > ). > > I know that in the past I spent enough time fixing PHP code that stopped > > working because of yet another BC change. That pace has slowed down in > > recent years. If you and others really don’t think this is a problem, > I’ll > > let you and those others fix the issues in the future as they are > unlikely > > to effect me. Just don’t say “we didn’t see it coming”. If I’m wrong, > them > > I’m wrong and feel to follow up with me in the last 2020’s when we know > > what has actually happened. > > > > … The whole point of deprecation notices is that nobody has any reason to > say “we didn’t see it coming”. What part of that don’t you understand? > > If a feature *of any kind* is listed as “deprecated” by the > vendor/project, and you’re still using it, the onus is on *you* to fix it. > That’s how deprecations work. > > > > Personally, I’m thinking of moving my backend work to something else, > like > > Go. Rob and his team seem to have a good handle on things. > > > > Great, good luck with that. > Thank you. I expect to have a blast learning a new language. > > > > > Cheers > >> > >> > >> Stephen > > > > > > > > Good luck, hope you don’t eventually cause too much pain and trouble with > > the BC breaks over the next few years. > > > > > > Walter > > > >> -- > > The greatest dangers to liberty lurk in insidious encroachment by men of > > zeal, well-meaning but without understanding. -- Justice Louis D. > Brandeis > > -- The greatest dangers to liberty lurk in insidious encroachment by men of zeal, well-meaning but without understanding. -- Justice Louis D. Brandeis
