Bash 5.0 released

Posted Jan 9, 2019 5:13 UTC (Wed) by Cyberax (✭ supporter ✭, #52523)
Parent article: Bash 5.0 released

Ugh.

These guys SERIOUSLY need to change something in their development model. Just look at their git: http://git.savannah.gnu.org/cgit/bash.git/log/

Bash 5.0 released

Posted Jan 9, 2019 7:59 UTC (Wed) by sytoka (guest, #38525) [Link]

fork and extend ;-)

Bash 5.0 released

Posted Jan 9, 2019 9:11 UTC (Wed) by XTerminator (subscriber, #59581) [Link] (35 responses)

What exactly are you talking about? Not possible to be constructive in your criticism?

Bash 5.0 released

Posted Jan 9, 2019 9:49 UTC (Wed) by zdzichu (guest, #17118) [Link] (4 responses)

I gather it's rather obvious from looking at Cyberax' link. Commit messages in Bash repository are completely useless. They do not explain why the change is done (and what the change is about, which is often not clear), short messages do not convey any meaning and 5.0 commit was a big code drop of bundled unrelated changes.

As for being constructive: there are number of “good commit messages” guides (random searches: https://medium.com/compass-true-north/writing-good-commit... https://code.likeagirl.io/useful-tips-for-writing-better-...). Adopting *any* of the guidelines would increase quality of Bash repo.

Bash 5.0 released

Posted Jan 9, 2019 9:52 UTC (Wed) by XTerminator (subscriber, #59581) [Link]

Thanks for the explanation. :)

Bash 5.0 released

Posted Jan 9, 2019 16:46 UTC (Wed) by Wol (subscriber, #4433) [Link] (1 responses)

On the other hand, all the changes were to tiny filesets apart from the last one. Plus the last one said DOCUMENTATION, implying it was NOT code.

My reading of this is maybe it's just simpler to look at the patch and it's documented there - although I will admit that that's a pain when you're trying to find which patch did something.

For a sole developer - seeing as all the commits were Chet - this doesn't seem to me at all unreasonable. Unless of course Cyberax knows more than me, he certainly seems to think there's more than one person maintaining bash ("these guys" - plural) - actually I'd be surprised ...

Cheers,
Wol

Bash 5.0 released

Posted Jan 10, 2019 17:52 UTC (Thu) by smurf (subscriber, #17840) [Link]

Huh? It says "Sources and documentation". Of course it's code. And translations. And libreadline. And every other friggin' thing that is mentioned in that announcement, plus very likely a bunch that are not.

Yeah, Chet seems to be the sole developer. And with good reason. With that kind of commit history I wouldn't even dream of helping with bash development. I also wouldn't help with security-or-whatever audits – this would be plenty reason to switch to a different shell, except for the fact that Debian's default shell is dash. :-P

No, being a single developer is not an excuse for shoddy commit management. How do you find regressions in that kind of mess??

Bash 5.0 released

Posted Jan 9, 2019 17:35 UTC (Wed) by sb (subscriber, #191) [Link]

Just to point out that they do document their changes (see http://git.savannah.gnu.org/cgit/bash.git/tree/CWRU/chang...). They just don't seem to want to do it in the commit messages.

Bash 5.0 released

Posted Jan 9, 2019 9:51 UTC (Wed) by lobachevsky (subscriber, #121871) [Link]

Well, there are tiny commits with unhelpful commit messages that are the patch releases and gigantic squashed source dumps for the major releases; no history beyond that.

Bash 5.0 released

Posted Jan 9, 2019 9:53 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (28 responses)

Their git repo is basically just a list of tarball dumps. It's useless.

Compare this to zsh: https://sourceforge.net/p/zsh/code/commit_browser

Bash 5.0 released

Posted Jan 9, 2019 23:15 UTC (Wed) by flussence (guest, #85566) [Link] (27 responses)

This git repo likely only exists to shut up demands from non-participating trophy collectors who expect every line of code on the internet to be compatible with github's “import” button.

If I'd been productive in a tarball+email workflow for 30 years and some slashdot/hn armchair developers showed up calling me out for not using their pet VCS, I'd be inclined to flash them a bit of malicious compliance too.

Bash 5.0 released

Posted Jan 10, 2019 2:40 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (26 responses)

> If I'd been productive in a tarball+email workflow for 30 years and some slashdot/hn armchair developers showed up calling me out for not using their pet VCS, I'd be inclined to flash them a bit of malicious compliance too.
Pure BS.

Patch + email workflow is compatible with multiple VCSes, starting from the venerable CVS. It can certainly be done with SVN, Mercurial and pretty much anything else more advanced than Microsoft SourceSafe.

Not maintaining usable history for a project like bash is bordering on insanity and criminal negligence these days.

Bash 5.0 released

Posted Jan 10, 2019 14:29 UTC (Thu) by Wol (subscriber, #4433) [Link] (25 responses)

> Not maintaining usable history for a project like bash is bordering on insanity and criminal negligence these days.

This is why so many critical infrastructure programs are poorly maintained! How many developers does bash have!?

If it's just Chet, he has every right to do it however it suits him. If you want to call best efforts "criminal negligence" that says more about you than him! There's plenty of "best practice" that I completely ignore because I don't have a 48hr day to do it in ...

Cheers,
Wol

Bash 5.0 released

Posted Jan 10, 2019 17:56 UTC (Thu) by smurf (subscriber, #17840) [Link] (5 responses)

This is not "best effort". Not by a very long shot. It's trivially easy to maintain a reasonable commit history.

Also, bash is security+mission critical software, if only by virtue of being the default login shell. While you don't exactly *need* a sensible change history for auditing the code, it'd make the job an order of magnitude easier.

Bash 5.0 released

Posted Jan 12, 2019 4:53 UTC (Sat) by rra (subscriber, #99804) [Link] (4 responses)

> Also, bash is security+mission critical software

Hmmm. I wonder if Chet is getting a paycheck proportionate to maintaining security and mission-critical software for the entire Internet. Or ever indicated any desire to be in that role or ever agreed to shoulder the responsibility for that. Or, in the absence of such a paycheck and agreement, why anyone should expect any particular workflow from him.

We certainly have a much larger problem here, namely that people have built critical infrastructure on top of free software without ever figuring out how to make this process rewarding, comfortable, and supportive for the people maintaining that free software. But then turning around and blaming them for not maintaining that software to the standards desired this critical infrastructure they were never involved in, never approved, aren't being paid for, and that never considered their feelings at all doesn't sit well with me.

Bash 5.0 released

Posted Jan 12, 2019 14:43 UTC (Sat) by smurf (subscriber, #17840) [Link] (3 responses)

I'm not blaming him. I'm saying that the practices of 20 years ago (a solo coder who periodically surfaces to release a tarball with the next version) do not make sense in today's world.

Chet may or may not want that responsibilty – but the fact is, he does have it. If he doesn't want it, then inviting collaborators and setting up a decent auditable workflow would seem to be a good idea. If he does, well, setting up a decent auditable workflow still is a good idea. We all make mistakes, and bash isn't exactly a simple program.

Bash 5.0 released

Posted Jan 12, 2019 15:29 UTC (Sat) by pizza (subscriber, #46) [Link]

Yes, today's world is not the same as the world 20 years ago. So why is today's world holding a solo coder to much higher (and time-consuming) standards while expecting said solo coder's compensation to be the same (ie nothing) as it was 20 years ago?

Bash 5.0 released

Posted Jan 12, 2019 18:43 UTC (Sat) by farnz (subscriber, #17727) [Link] (1 responses)

Why should Chet change a workflow that works for him just because other people have started to depend on his work without doing sufficient due diligence to ensure that what he's doing fits theit needs? Instead, why don't people who don't want to depend on Chet's workflow switch to one of dash, zsh or ksh (to name three Bourne shells that aren't bash). Alternatively, why don't people who care fork bash and work on it in ways that they think are better?

Basically, why should Chet be expected to change because other people like his work? Why can't his work be allowed to fade into historical obscurity?

Bash 5.0 released

Posted Jan 14, 2019 12:09 UTC (Mon) by Wol (subscriber, #4433) [Link]

> Basically, why should Chet be expected to change because other people like his work? Why can't his work be allowed to fade into historical obscurity?

Or, if people really do want to depend on his work, why can't they start paying him to do it!!!

I'm probably as much the cheapskate as anyone else, but I do try and give back in kind. If you're not prepared to "put your money where your mouth is" you have no right to moan, and if you are prepared then you probably have a far better view of the situation.

The reality is MUCH important software is in this sort of mess, because nobody is prepared to put their hand in their pocket. One piece of software I use has a sole dedicated developer, who is struggling to make ends meet and is also fighting illness. How's that fair? He's doing his best to support Free Software and not doing very well out of it ...

Cheers,
Wol

Bash 5.0 released

Posted Jan 11, 2019 14:44 UTC (Fri) by rleigh (guest, #14622) [Link] (18 responses)

Commits containing only a single focussed change with descriptive log messages is not exactly new. Plenty of projects have been doing this for decades, right back to CVS/RCS. There's nothing git-specific about this practice. Having a bunch of unrelated disparate changes in a single commit with nondescript log messages removes much of the value of having version control.

Bash 5.0 released

Posted Jan 14, 2019 12:14 UTC (Mon) by Wol (subscriber, #4433) [Link] (17 responses)

> Having a bunch of unrelated disparate changes in a single commit with nondescript log messages removes much of the value of having version control.

What value is that? Not what value do YOU place on it, but what value does CHET place on it.

You can't base your argument on your values. I regularly get peed of by BT adverts saying "we're sure you'll love our heavily discounted (yeah ...) SIMS at £10 each". That's if you buy 5 of them! I pay £9 for two sims, with more data, calls and texts than my wife and I ever use. £10/SIM may be great value from BT's point of view, but from mine it's a waste of money ...

Cheers,
Wol

Bash 5.0 released

Posted Jan 15, 2019 11:28 UTC (Tue) by cagrazia (guest, #124754) [Link] (15 responses)

I think there's no need to argue for one position or the other. It is crystal clear that bash should be deprecated as soon as possible by all distribution, as it is more a hobbyware than a real critical-mission software.

Bash 5.0 released

Posted Jan 15, 2019 12:00 UTC (Tue) by pizza (subscriber, #46) [Link]

Make no mistake, the only reason most folks use F/OSS is because "someone else" pays for its development.

Yank bash, and a sizeable portion of the internet will break. It is "hobbyware" only in the sense that nobody other than its authors care about it sufficiently enough to meaningfully contribute to its upkeep.

Meanwhile, even "deprecating" bash requires a nontrivial amount ongoing effort that you're expecting "someone else" to do -- ie pay for.

Bash 5.0 released

Posted Jan 20, 2019 2:54 UTC (Sun) by dualbus (guest, #129437) [Link] (12 responses)

It is mind boggling how dismissive you're being of other people's work and effort, just because they don't make commits in a specific way.

Bash 5.0 released

Posted Jan 20, 2019 3:30 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link] (11 responses)

No it's not. Because eventually somebody else will have to dig through the history in order to find out the source of the next vulnerability.

It also increases the chances of the next MD_Update disaster.

Bash 5.0 released

Posted Jan 20, 2019 4:10 UTC (Sun) by pizza (subscriber, #46) [Link] (10 responses)

So you are saying that someone else might have to do some work at some unspecified time in the future? Stop the internets!

Meanwhile, this little statement is worth repeating:

"Bash is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details."

Bash 5.0 released

Posted Jan 20, 2019 4:13 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link] (5 responses)

> So you are saying that someone else might have to do some work at some unspecified time in the future? Stop the internets!
Yes. If you're building public infrastructure then you MUST plan for the future. Is it that difficult to understand?

Bash 5.0 released

Posted Jan 20, 2019 13:30 UTC (Sun) by pizza (subscriber, #46) [Link] (4 responses)

> Yes. If you're building public infrastructure then you MUST plan for the future. Is it that difficult to understand?

If *I* am building infrastructure, then *I* will make plans to handle "unspecified stuff going wrong"

What I don't do is expect other folks to do any (additional) unpaid work on behalf of my infrastructure, and I certainly don't denigrate the folks whose work I am already taking advantage of -- because, speaking personally about the Free Software I have released, I'm far more inclined to promptly help out folks that are respectful of the work I have already done, acknowledge that I owe them nothing, and who have not been publicly badmouthing me.

Is *that* so difficult to understand?

Bash 5.0 released

Posted Jan 20, 2019 20:41 UTC (Sun) by mjg59 (subscriber, #23239) [Link] (3 responses)

Two things that can simultaneously be true:

1) Chet's work is a great gift to the free software community and we have benefited hugely from it over decades

2) Over that time we've learned that there are ways to maintain software that make it easier for others to consume that work, contribute code back and identify and fix issues. Now that we're aware that there are better ways to do it, we're also aware of the additional costs imposed on consumers by not having a fine grained revision history. Overall people still seem to feel that the benefits provided by bash outweigh the drawbacks, but if it /were/ possible to convince Chet to change the way bash is maintained, life would still be better.

Bash 5.0 released

Posted Jan 20, 2019 22:30 UTC (Sun) by pizza (subscriber, #46) [Link]

> but if it /were/ possible to convince Chet to change the way bash is maintained, life would still be better.

No argument from me there!

...but whether or not it is possible to convince him to change his ways, denigrating him and his work is not the way to accomplish it.

Bash 5.0 released

Posted Jan 21, 2019 2:29 UTC (Mon) by pabs (subscriber, #43278) [Link] (1 responses)

Has anyone talked to Chet about changing to a more fine grained revision history before?

Bash 5.0 released

Posted Jan 21, 2019 6:32 UTC (Mon) by dualbus (guest, #129437) [Link]

The initial git migration was discussed here: http://lists.nongnu.org/archive/html/bug-bash/2011-11/msg...

And the only time I'm aware of it being brought up as a specific discussion topic is here: https://lists.gnu.org/archive/html/bug-bash/2015-03/msg00... (spoiler alert: I gave up really quickly on maintaining that mirror)

Bash 5.0 released

Posted Jan 20, 2019 11:13 UTC (Sun) by smurf (subscriber, #17840) [Link] (3 responses)

Yeah. We all know the boilerplate in those licenses. All programs have them. So does the kernel. So what?

The code is, effectively, less auditable and thus less secure when all you see is a sequence of tarballs. Chet appears not to care about any of that. His choice – but it confirms the decision to switch away from Bash which some (most?) distributions took, years ago, for performance/memory usage reasons.

Bash 5.0 released

Posted Jan 20, 2019 13:43 UTC (Sun) by pizza (subscriber, #46) [Link] (2 responses)

So you're saying that, somehow, "caveat emptor" doesn't apply here?

If Bash's development practices are somehow unacceptable to you, there are three ways to proceed. Convince its author to do what you want, fork it and do a better job, or switch to something "better". Either way it's going to cost you time, effort, and a non-trivial amount of hard currency.

(And yes, some distributions have switched away from bash for system scripts, primarily for reasons that have since been rendered irrelevant by systemd...)

Bash 5.0 released

Posted Jan 20, 2019 20:48 UTC (Sun) by smurf (subscriber, #17840) [Link] (1 responses)

No, I'm saying that c.e. applies to everything. Bash dash openssh kernel libreoffice windows msoffice – doesn't matter, they all say that, they only differ in how many words they use.

The difference is that most of these acknowledge that their code is used in security critical areas anyway, and have started to adapt their practices accordingly. Apparently, Chet has not. As I wrote, his choice, just as mine is to hack on any script I come across until it no longer says #!/bin/bash on top.

Bash 5.0 released

Posted Jan 21, 2019 6:40 UTC (Mon) by dualbus (guest, #129437) [Link]

> The difference is that most of these acknowledge that their code is used in security critical areas anyway, and have started to adapt their practices accordingly. Apparently, Chet has not. (...)

What does git have to do with security? I read the weekly change sets when they're pushed, and I have no trouble understanding what's being changed or why. Sure, it might not be the commit /style/ you prefer, but has little to do with the quality of the software, or its security characteristics.

Also, perhaps ask Chet to provide more detailed / specific commits instead of just assuming he doesn't want to?

Bash 5.0 released

Posted Jan 20, 2019 13:27 UTC (Sun) by flussence (guest, #85566) [Link]

You might be in for a rude awakening if you continue to feel entitled to infinite return on investment from all the software you use.

Appropriate use of version control

Posted Jan 18, 2019 15:21 UTC (Fri) by rleigh (guest, #14622) [Link]

Version control serves several purposes. Most of them rely upon having a clean history. Firstly, having clear and appropriate commit messages helps to find changes in the history when you need to find when a particular change was made. Secondly, having discrete changes in each commit makes it easier to revert selected changes, as well as to review changes in isolation.

The existing approach may work for the maintainer, and that's fair enough. It's his project. But, it does greatly reduce the utility of the project history both for himself and for anyone else who wants to work upon it. There are existing good practices for using version control, and this approach violates many of them.