On 8 October 2014 12:35, Miloslav Trmač wrote:
Been away for a week and come back to this nonsense. Why put so much
effort into arguing *against* having the right interpreter listed at
the top of a script. Seems pretty perverse to insist it should be
/bin/sh to maintain a conflation that's unique
On Wed, Oct 8, 2014 at 5:11 PM, Gerald B. Cox wrote:
> My thought is this whole topic was started as a result of the recent Bash
> vulnerability which has since been corrected. Not bad for a product that
> has been around for decades. Nothing against Dash, but changing a default
> isn't somethi
On Thu, 2 Oct 2014 14:12:12 +0100
"Daniel P. Berrange" wrote:
> I'd be curious of the results if someone wants to take a stock Fedora 21
> install and switch /bin/sh to point to dash and report if they can still
> boot & login to GNOME.
I did a smaller run on a server without GNOME. Had to chage
My thought is this whole topic was started as a result of the recent Bash
vulnerability which has since been corrected. Not bad for a product that
has been around for decades. Nothing against Dash, but changing a default
isn't something that should be done each time the wind changes direction.
A
- Original Message -
> On 6 October 2014 17:28, Miloslav Trmač wrote:
> > - Original Message -
> >> > usage/requirement as well. Bringing the benefits of supporting dash to…
> >> > the satisfaction of pedantically using the POSIX /bin/sh path as
> >> > frequently as possible?
> >>
On 6 October 2014 17:28, Miloslav Trmač wrote:
> - Original Message -
>> > At that point switching anything to dash can _only increase_, not reduce,
>> > the disk space needed, and is very likely to increase the total page cache
>> > usage/requirement as well. Bringing the benefits of sup
- Original Message -
> > At that point switching anything to dash can _only increase_, not reduce,
> > the disk space needed, and is very likely to increase the total page cache
> > usage/requirement as well. Bringing the benefits of supporting dash to…
> > the satisfaction of pedantically
On 6 October 2014 16:57, Miloslav Trmač wrote:
> - Original Message -
>> On Fri, Oct 03, 2014 at 02:29:53PM -0600, Orion Poplawski wrote:
>> > >Is it worth considering using Dash as the default (non-interactive)
>> > >shell in Fedora? Other distributions including Ubuntu and Debian
>> > >
- Original Message -
> On Fri, Oct 03, 2014 at 02:29:53PM -0600, Orion Poplawski wrote:
> > >Is it worth considering using Dash as the default (non-interactive)
> > >shell in Fedora? Other distributions including Ubuntu and Debian
> > >(https://lwn.net/Articles/343924/) have been using das
On 6 October 2014 00:06, Paolo Bonzini wrote:
> Il 02/10/2014 11:04, Zdenek Kabelac ha scritto:
> > It used to give significant boost for automake & libtool based software
> > - however at some point libtool started to use bashisms and so you
> > cannot just replace /bin/sh -> dash - as build wi
On Sat, Oct 4, 2014 at 8:37 AM, Panu Matilainen
wrote:
>
> I'm sure rpmlint can (be made to) check for bashisms...
https://sourceforge.net/p/rpmlint/tickets/39/
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http
On 10/06/2014 08:57 AM, Zdenek Kabelac wrote:
Well all I can say is autoconf (at least on my rawhide) doesn't work
with dash for quite some time.
Care to share more details?
Could be a dash bug, could be an autoconf bug, could be a local
configuration breakage, could be something else.
Ralf
Dne 6.10.2014 v 08:06 Paolo Bonzini napsal(a):
Il 02/10/2014 11:04, Zdenek Kabelac ha scritto:
It used to give significant boost for automake & libtool based software
- however at some point libtool started to use bashisms and so you
cannot just replace /bin/sh -> dash - as build will fail.
T
Dne 6.10.2014 v 08:21 Paolo Bonzini napsal(a):
Il 04/10/2014 18:17, Zdenek Kabelac ha scritto:
And yes - with UsrMove we lost distinction between
what are system tools
and
what are usr tools.
What you call "system tools" is simply the content of the initramfs.
Paolo
Close - but not exactly
Il 04/10/2014 18:17, Zdenek Kabelac ha scritto:
>
> And yes - with UsrMove we lost distinction between
> what are system tools
> and
> what are usr tools.
What you call "system tools" is simply the content of the initramfs.
Paolo
--
devel mailing list
devel@lists.fedoraproject.org
https://admin
Il 02/10/2014 11:04, Zdenek Kabelac ha scritto:
> It used to give significant boost for automake & libtool based software
> - however at some point libtool started to use bashisms and so you
> cannot just replace /bin/sh -> dash - as build will fail.
This is wrong.
libtool detects whether you ca
Dne 4.10.2014 v 18:08 Florian Weimer napsal(a):
On 10/04/2014 06:03 PM, Zdenek Kabelac wrote:
We still have universal:
#/usr/bin/env bash
Sadly, some systems have /bin/env, but not /usr/bin/env.
Sadly it's fault of that distro - Fedora is not here to fix other distro
mistakes...
'env' i
Am 04.10.2014 um 18:08 schrieb Florian Weimer:
On 10/04/2014 06:03 PM, Zdenek Kabelac wrote:
We still have universal:
#/usr/bin/env bash
Sadly, some systems have /bin/env, but not /usr/bin/env
on the Fedoras side a non-brainer
just use /bin/env since after UsrMove both works
signature.a
On 10/04/2014 06:03 PM, Zdenek Kabelac wrote:
We still have universal:
#/usr/bin/env bash
Sadly, some systems have /bin/env, but not /usr/bin/env.
--
Florian Weimer / Red Hat Product Security
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/
Dne 4.10.2014 v 18:00 Florian Weimer napsal(a):
On 10/04/2014 01:05 AM, Rahul Sundaram wrote:
On Fri, Oct 3, 2014 at 6:59 PM, Nico Kadel-Garci wrote:
And it's going to break backports to EPEL for RHEL 5 or RHEL 6, or
CentOS or Scientific Linux, pretty seriously
Please explain how.
On 10/04/2014 01:05 AM, Rahul Sundaram wrote:
On Fri, Oct 3, 2014 at 6:59 PM, Nico Kadel-Garci wrote:
And it's going to break backports to EPEL for RHEL 5 or RHEL 6, or
CentOS or Scientific Linux, pretty seriously
Please explain how.
Systems which haven't undergone UsrMove don't hav
On 10/04/2014 01:04 AM, Orion Poplawski wrote:
On 10/03/2014 03:55 PM, Orion Poplawski wrote:
On 10/03/2014 02:34 PM, Matthew Miller wrote:
On Fri, Oct 03, 2014 at 02:29:53PM -0600, Orion Poplawski wrote:
Is it worth considering using Dash as the default (non-interactive)
shell in Fedora? Oth
Hi
On Fri, Oct 3, 2014 at 7:23 PM, Chris Adams wrote:
>
> To be fair, portable programs wrap GCCisms in #ifdefs.
>
Indeed. To wrap this up for now, I have filed
https://fedorahosted.org/fesco/ticket/1352
Rahul
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.o
Once upon a time, Jakub Jelinek said:
> But why? Seriously, bash has lots of nice extensions, are you going in this
> quest to stop using extensions going to suggest that we get rid of GNU C
> library extensions usages in the distro programs next, or GCC extensions,
> what else?
To be fair, port
Hi
On Fri, Oct 3, 2014 at 7:12 PM, Jakub Jelinek wrote:
>
> But why? Seriously, bash has lots of nice extensions, are you going in
> this
> quest to stop using extensions
>
You seem to have misread what I said. Bash is great and I love some of
the extensions but if you want to use bash, just
On Fri, Oct 03, 2014 at 06:14:05PM -0400, Rahul Sundaram wrote:
> On Fri, Oct 3, 2014 at 9:04 AM, Garry T. Williams
> wrote:
>
> >
> > $ (checkbashisms -f -p $(grep -rlE '^#! ?/bin/(env )?sh' /usr/bin) )
> > 2>&1 >/dev/null|grep 'possible bashism'|awk '{print $4}'|sort -u|wc -l
> > 113
>
Hi
On Fri, Oct 3, 2014 at 6:59 PM, Nico Kadel-Garci wrote:
> And it's going to break backports to EPEL for RHEL 5 or RHEL 6, or
> CentOS or Scientific Linux, pretty seriously
>
Please explain how.
Rahul
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailma
On Fri, Oct 3, 2014 at 6:14 PM, Rahul Sundaram wrote:
> Hi
>
> On Fri, Oct 3, 2014 at 9:04 AM, Garry T. Williams
> wrote:
>>
>>
>> $ (checkbashisms -f -p $(grep -rlE '^#! ?/bin/(env )?sh' /usr/bin) )
>> 2>&1 >/dev/null|grep 'possible bashism'|awk '{print $4}'|sort -u|wc -l
>> 113
>> $
Hi
On Fri, Oct 3, 2014 at 9:04 AM, Garry T. Williams
wrote:
>
> $ (checkbashisms -f -p $(grep -rlE '^#! ?/bin/(env )?sh' /usr/bin) )
> 2>&1 >/dev/null|grep 'possible bashism'|awk '{print $4}'|sort -u|wc -l
> 113
> $
>
> Many of these trigger multiple warnings from checkbashisms. The
On 10/03/2014 03:55 PM, Orion Poplawski wrote:
On 10/03/2014 02:34 PM, Matthew Miller wrote:
On Fri, Oct 03, 2014 at 02:29:53PM -0600, Orion Poplawski wrote:
Is it worth considering using Dash as the default (non-interactive)
shell in Fedora? Other distributions including Ubuntu and Debian
(ht
On 10/03/2014 02:34 PM, Matthew Miller wrote:
On Fri, Oct 03, 2014 at 02:29:53PM -0600, Orion Poplawski wrote:
Is it worth considering using Dash as the default (non-interactive)
shell in Fedora? Other distributions including Ubuntu and Debian
(https://lwn.net/Articles/343924/) have been using
On Fri, Oct 03, 2014 at 02:29:53PM -0600, Orion Poplawski wrote:
> >Is it worth considering using Dash as the default (non-interactive)
> >shell in Fedora? Other distributions including Ubuntu and Debian
> >(https://lwn.net/Articles/343924/) have been using dash as the default
> >shell and Android
On 10/01/2014 08:39 PM, Rahul Sundaram wrote:
Hi
Is it worth considering using Dash as the default (non-interactive)
shell in Fedora? Other distributions including Ubuntu and Debian
(https://lwn.net/Articles/343924/) have been using dash as the default
shell and Android uses mksh. While this a
On 10-2-14 10:01:45 Rahul Sundaram wrote:
> On Thu, Oct 2, 2014 at 9:56 AM, Miroslav Suchý wrote:
> > On 10/02/2014 04:39 AM, Rahul Sundaram wrote:
> >> Is it worth considering using Dash as the default (non-interactive) shell
> >> in Fedora?
> >
> > Why starting with changing target of /bin/sh?
>
Hi
On Thu, Oct 2, 2014 at 4:56 PM, Reindl Harald wrote:
> then that paragraph refer to Shellshock was not really appropriate without
> make really clear that this is not a panic reaction in context of already
> fixed bash bugs
>
I didn't think one would assume it is just a panic reaction if the
Am 02.10.2014 um 22:45 schrieb Rahul Sundaram:
> On Thu, Oct 2, 2014 at 11:57 AM, Reindl Harald wrote:
>
> because the conclusion that dash is not vulerable for
> other things is invalid
>
>
> I am afraid there was no such conclusions. To acknowledge known bugs in bash
> doesn't requi
Hi
On Thu, Oct 2, 2014 at 11:57 AM, Reindl Harald wrote:
>
> because the conclusion that dash is not vulerable for
> other things is invalid
>
I am afraid there was no such conclusions. To acknowledge known bugs in
bash doesn't require anyone to conclude that dash doesn't have bugs.
Rahul
--
On 2 October 2014 13:59, Chris Adams wrote:
> Once upon a time, Lennart Poettering said:
>
>> In general, I am pretty sure that except a couple of programming
>> language or UNIX aficionades very few people can actually correctly
>> separate bashisms from true bourneshellisms.
>
> It isn't that
On 2 October 2014 17:13, Ralf Corsepius wrote:
> On 10/02/2014 03:07 PM, Rahul Sundaram wrote:
>>
>> Hi
>>
>> On Thu, Oct 2, 2014 at 8:59 AM, Chris Adams wrote:
>>
>>
>> If that's the case, why do we have the /bin/sh symlink? Just remove
>> it
>> and make the bash dependency explicit (so
Hi
On Thu, Oct 2, 2014 at 11:59 AM, Tom Rivers wrote:
> You know, you could've simply replied to my original take on your
> self-described opportunistic proposal with something like, "No, Tom, I'm
> not just making this proposal because of Shellshock. I really think there
> are some merits to d
Am 02.10.2014 um 19:08 schrieb Bruno Wolff III:
> On Thu, Oct 02, 2014 at 13:05:27 -0400,
> Matthew Miller wrote:
>>
>> For the case of arbitrary variables (like USER_AGENT), the problem is
>> closed, because now only variables prefixed BASH_FUNC_ and with a suffix of
>> () in our current patch
On Thu, Oct 02, 2014 at 13:05:27 -0400,
Matthew Miller wrote:
For the case of arbitrary variables (like USER_AGENT), the problem is
closed, because now only variables prefixed BASH_FUNC_ and with a suffix of
() in our current patch or %% upstream are scanned for function definitions.
Thanks
On Thu, Oct 02, 2014 at 11:22:18AM -0500, Bruno Wolff III wrote:
> I think the disconnect there was that people assumed that as long as
> you controlled which environment variables (by name) were passed you
> were OK. It was assumed that the values weren't processed outside of
> what you explicitly
Dne 2.10.2014 v 18:00 Haïkel napsal(a):
2014-10-02 17:56 GMT+02:00 Tomasz Torcz :
Also it will reduce differences between Linux distribution. And take us
closed to what majority (Ubuntu and Debian) does.
I don't see the point, now that we use systemd ...
Besides, even on Debian/Ubuntu, Ba
Hi
On Thu, Oct 2, 2014 at 12:13 PM, Ralf Corsepius wrote:
No. /bin/sh is supposed to be a POSIX-compatible shell.
>
Right. This is what I meant. We can't just remove /bin/sh completely and
require users to always use dash or bash explicitly. Whether it is a
symlink and what precisely it poin
On Thu, Oct 02, 2014 at 11:59:54 -0400,
Miloslav Trmač wrote:
As I said in the snipped part, anyone able to submit arbitrary input to a shell
can already cause it to do arbitrary things. The parser bugs do not give the
attacker anything they don’t already have, so they are not security-relev
On 10/02/2014 03:07 PM, Rahul Sundaram wrote:
Hi
On Thu, Oct 2, 2014 at 8:59 AM, Chris Adams wrote:
If that's the case, why do we have the /bin/sh symlink? Just remove it
and make the bash dependency explicit (so everything has to call
/bin/bash).
I understand this is a rherotic
On Thu, Oct 02, 2014 at 05:56:17PM +0200, Tomasz Torcz wrote:
> Also it will reduce differences between Linux distribution. And take us
> closed to what majority (Ubuntu and Debian) does.
We don't need to follow Ubuntu or Debian in every not-so-smart decision they
make, we haven't followed them
2014-10-02 17:56 GMT+02:00 Tomasz Torcz :
>
> Also it will reduce differences between Linux distribution. And take us
> closed to what majority (Ubuntu and Debian) does.
>
I don't see the point, now that we use systemd ...
Besides, even on Debian/Ubuntu, Bash is still the most popular script
she
> The expected security improvement is essentially nonexistent. In the current
> case of importing functions from the environment (and we could have a looong
> philosophical conversation about whether this is a vulnerability in bash or
> in its callers, where the likely outcome is “not a vulnerabil
On 10/2/2014 11:13, Rahul Sundaram wrote:
Sure but the rationale isn't just security as I have explained
earlier. Do read the links and other mails fully.
I have read the emails fully. Sure, I see where you said there were
other reasons later in the discussion, but that's not what your origi
Am 02.10.2014 um 17:53 schrieb Rahul Sundaram:
> On Thu, Oct 2, 2014 at 11:38 AM, Miloslav Trmač wrote:
> The expected security improvement is essentially nonexistent. In the
> current case of importing functions from
> the environment (and we could have a looong philosophical conversat
On Thu, Oct 02, 2014 at 11:53:18AM -0400, Rahul Sundaram wrote:
> Hi
>
> On Thu, Oct 2, 2014 at 11:38 AM, Miloslav Trmač wrote:
>
> >
> > OK, then; care to explicitly list the advantages you expect to see from
> > such a switch, and why they outweigh the disadvantages and the migration
> > costs
I don't see any real benefit to move to dash since we get rid of sysV
init, no security improvements, but a lot of breakages to fix (Debian
spent a lot of time to fix bashisms in their packages ...)
That doesn't mean that we shouldn't consider it -this is a sane to
periodically re-assess our defaul
Hi
On Thu, Oct 2, 2014 at 11:38 AM, Miloslav Trmač wrote:
>
> OK, then; care to explicitly list the advantages you expect to see from
> such a switch, and why they outweigh the disadvantages and the migration
> costs?
>
I don't have a predrawn conclusion that I am advocating strongly for here
b
Hello,
> On Thu, Oct 2, 2014 at 10:48 AM, Tom Rivers wrote:
> > On 10/2/2014 09:58, Rahul Sundaram wrote:
>
> > > I didn't address it because it was not really relevant either. The
> > > impetus
> > > is
> > > merely the backstory.
> >
>
> > On the contrary, the rationale for your proposed
On Wed, Oct 01, 2014 at 10:39:04PM -0400, Rahul Sundaram wrote:
> Is it worth considering using Dash as the default (non-interactive) shell
> in Fedora? Other distributions including Ubuntu and Debian (
Thanks for bringing up the discussion. Just as we shouldn't change things
for no reason, we
Hi
On Thu, Oct 2, 2014 at 10:48 AM, Tom Rivers wrote:
> On 10/2/2014 09:58, Rahul Sundaram wrote:
>
>> I didn't address it because it was not really relevant either. The
>> impetus is merely the backstory.
>>
>
> On the contrary, the rationale for your proposed change is very relevant.
>
Sure b
On 10/2/2014 09:58, Rahul Sundaram wrote:
I didn't address it because it was not really relevant either. The
impetus is merely the backstory.
On the contrary, the rationale for your proposed change is very
relevant. The reasons for undertaking a project of this magnitude
should be substantia
On 10/02/2014 03:07 PM, Chris Adams wrote:
Once upon a time, Richard W.M. Jones said:
Changing the default /bin/sh is going to break the world.
[citation needed]
Just look for brace expansion in spec files. It's use is *extremely*
common. And many of the failures are silent, e.g. argumen
On Thu, Oct 02, 2014 at 03:21:33PM +0200, Lennart Poettering wrote:
> I am more concerned about code written by admins and users. I kinda
> hope that we don't ship too massive shell programs in Fedora, (well,
> except of course autoconf scripts...), but I am pretty sure that shell
> is one of the m
Hi
On Thu, Oct 2, 2014 at 9:56 AM, Miroslav Suchý wrote:
> On 10/02/2014 04:39 AM, Rahul Sundaram wrote:
>
>> Is it worth considering using Dash as the default (non-interactive) shell
>> in Fedora?
>>
>
> Why starting with changing target of /bin/sh?
>
> Can we start with smaller step?
> Like pu
Once upon a time, Miroslav Suchý said:
> Like put in Packing Guidelines, that authors and maintainers of
> non-interactive shell scripts should use
> #!/usr/bin/dash
> rather then
> #!/bin/sh or
> #!/usr/bin/bash
No, /bin/sh is the standard-defined definitive place for the
POSIX-compliant
Hi
On Thu, Oct 2, 2014 at 9:49 AM, Tom Rivers wrote:
> While I appreciate your technical correction on the scope of this proposed
> switch, you conveniently failed to address the core argument I made which
> is by far the larger issue: the impetus...
>
I didn't address it because it was not re
On 10/02/2014 04:39 AM, Rahul Sundaram wrote:
Is it worth considering using Dash as the default (non-interactive) shell in
Fedora?
Why starting with changing target of /bin/sh?
Can we start with smaller step?
Like put in Packing Guidelines, that authors and maintainers of non-interactive
she
Hi
On Thu, Oct 2, 2014 at 9:42 AM, Josh Boyer wrote:
> But the prompt for doing so is a security incident that has already
> been fixed. If this was really a worthwhile endeavour, why hasn't it
> come up before?
>
Our needs continue to evolve. We didn't consider size as much before but
there i
On 10/2/2014 09:27, Rahul Sundaram wrote:
That is a mischaracterization. Bash will remain the interactive
shell. This discussion is limited to switching the system shell
(/bin/sh) from Bash to potentially Dash.
While I appreciate your technical correction on the scope of this
proposed switc
On Thu, Oct 2, 2014 at 9:27 AM, Rahul Sundaram wrote:
> Hi
>
> On Thu, Oct 2, 2014 at 9:18 AM, Tom Rivers wrote:
>>
>> So there's a vulnerability found in bash, it gets patched almost
>> immediately, and all of a sudden there's a push to abandon it altogether?
>
>
> That is a mischaracterization.
On Thu, Oct 02, 2014 at 08:05:09AM -0500, Chris Adams wrote:
> Once upon a time, Lennart Poettering said:
> > If you change /bin/sh to dash, then you'll have to map two shell
> > binaries into memory (since the login shell is going to stay on bash),
> > hence the resource usage grows.
>
> systemd
Hi
On Thu, Oct 2, 2014 at 9:18 AM, Tom Rivers wrote:
> So there's a vulnerability found in bash, it gets patched almost
> immediately, and all of a sudden there's a push to abandon it altogether?
>
That is a mischaracterization. Bash will remain the interactive shell.
This discussion is limited
On Thu, 02.10.14 14:12, Daniel P. Berrange (berra...@redhat.com) wrote:
> On Thu, Oct 02, 2014 at 08:07:14AM -0500, Chris Adams wrote:
> > Once upon a time, Richard W.M. Jones said:
> > > Changing the default /bin/sh is going to break the world.
> >
> > [citation needed]
> >
> > Anything that d
On 10/1/2014 22:39, Rahul Sundaram wrote:
Since the recent Shellshock aka Bashdoor vulnerability, there have
been some discussions about more distributions switching over...
So there's a vulnerability found in bash, it gets patched almost
immediately, and all of a sudden there's a push to ab
On Thu, Oct 02, 2014 at 08:07:14AM -0500, Chris Adams wrote:
> Once upon a time, Richard W.M. Jones said:
> > Changing the default /bin/sh is going to break the world.
>
> [citation needed]
>
> Anything that depends on bash as /bin/sh is already getting Fedora
> specific. Debian/Ubuntu don't us
Hi
On Thu, Oct 2, 2014 at 8:59 AM, Chris Adams wrote:
>
> If that's the case, why do we have the /bin/sh symlink? Just remove it
> and make the bash dependency explicit (so everything has to call
> /bin/bash).
>
I understand this is a rherotical argument but the symlink exists because
it is re
Once upon a time, Richard W.M. Jones said:
> Changing the default /bin/sh is going to break the world.
[citation needed]
Anything that depends on bash as /bin/sh is already getting Fedora
specific. Debian/Ubuntu don't use bash as /bin/sh for years, and none
of the other major Unix-like systems
Once upon a time, Lennart Poettering said:
> If you change /bin/sh to dash, then you'll have to map two shell
> binaries into memory (since the login shell is going to stay on bash),
> hence the resource usage grows.
systemd (as PID 1, not counting additional required processes) takes
over 10 tim
Once upon a time, Lennart Poettering said:
> The shell is API.
Yep, and that API is the POSIX shell language, an extended version of
the Bourne shell. It is a Linux curiousity that came along to use bash
as /bin/sh.
> Currently, if people write shell (#!/bin/sh) scripts
> on Fedora, they can be
On Thu, 2014-10-02 at 12:07 +0200, Ralf Corsepius wrote:
> On 10/02/2014 11:25 AM, Balint Szigeti wrote:
> > On Thu, 2014-10-02 at 10:58 +0200, Ralf Corsepius wrote:
> >> On 10/02/2014 10:32 AM, Balint Szigeti wrote:
> >> > hello
> >> >
> >> > Don't we consider using zsh?
> >>
> >> I'd rather not.
Am 02.10.2014 um 09:14 schrieb Tomasz Torcz:
> On Thu, Oct 02, 2014 at 08:33:23AM +0200, Lennart Poettering wrote:
>> since you have two packages to look after (Yes, by adding dash to the
>> default stack you just put the extra burden on Fedora to quickly
>> update two packages instead of just one
On 10/02/2014 11:25 AM, Balint Szigeti wrote:
On Thu, 2014-10-02 at 10:58 +0200, Ralf Corsepius wrote:
On 10/02/2014 10:32 AM, Balint Szigeti wrote:
> hello
>
> Don't we consider using zsh?
I'd rather not. Thoughout its history, zsh has had lots of issues
originating from limitations, bugs and
On 10/02/2014 11:04 AM, Zdenek Kabelac wrote:
Dne 2.10.2014 v 10:40 Ralf Corsepius napsal(a):
On 10/02/2014 09:47 AM, Zdenek Kabelac wrote:
Dne 2.10.2014 v 08:33 Lennart Poettering napsal(a):
It used to give significant boost for automake & libtool based software
- however at some point lib
On Thu, 2014-10-02 at 10:58 +0200, Ralf Corsepius wrote:
> On 10/02/2014 10:32 AM, Balint Szigeti wrote:
> > hello
> >
> > Don't we consider using zsh?
>
> I'd rather not. Thoughout its history, zsh has had lots of issues
> originating from limitations, bugs and incompatibilities.
hm... Interes
Dne 2.10.2014 v 10:40 Ralf Corsepius napsal(a):
On 10/02/2014 09:47 AM, Zdenek Kabelac wrote:
Dne 2.10.2014 v 08:33 Lennart Poettering napsal(a):
On the other hand - usage of dash significantly speeds up compilation of
autoconf projects - it's pretty interesting to see the compilation with
d
On 10/02/2014 10:32 AM, Balint Szigeti wrote:
hello
Don't we consider using zsh?
I'd rather not. Thoughout its history, zsh has had lots of issues
originating from limitations, bugs and incompatibilities.
I don't know about the current situation, but e.g., the configure
scripts I just post
On 2014-10-02 10:25, Rahul Sundaram wrote:
>> It doesn't even avoid Debian & Ubuntu having a security problem, since
>> they still need to fix bash.
>
> Sure. Unless they stop shipping bash, they got to fix security problems.
> That is no surprise. The real question is whether it reduced the imp
On 10/02/2014 09:47 AM, Zdenek Kabelac wrote:
Dne 2.10.2014 v 08:33 Lennart Poettering napsal(a):
On the other hand - usage of dash significantly speeds up compilation of
autoconf projects - it's pretty interesting to see the compilation with
dash
is then maybe even 50% faster in non optimize
hello
Don't we consider using zsh?
Balint
On Thu, 2014-10-02 at 10:04 +0200, Florian Weimer wrote:
> On 10/02/2014 09:14 AM, Tomasz Torcz wrote:
>
> >/bin/sh isn't supposed to "stay in memory". It's for one-off scripts,
> > not for interactive use.
>
> It will stay in memory around comman
Hi
On Thu, Oct 2, 2014 at 4:04 AM, Richard W.M. Jones wrote:
> On Wed, Oct 01, 2014 at 10:39:04PM -0400, Rahul Sundaram wrote:
> For Ubuntu the stated reason to follow Debian was pretty bogus[1] --
>
Ubuntu didn't follow Debian here. It was the other way around.
>
> It doesn't even avoid Debi
On 10/02/2014 09:14 AM, Tomasz Torcz wrote:
/bin/sh isn't supposed to "stay in memory". It's for one-off scripts,
not for interactive use.
It will stay in memory around command invocations, and the executable
code and mapped data will remain in the page cache (hopefully).
Allegedly, dash
On Wed, Oct 01, 2014 at 10:39:04PM -0400, Rahul Sundaram wrote:
> Hi
>
> Is it worth considering using Dash as the default (non-interactive) shell
> in Fedora? Other distributions including Ubuntu and Debian (
> https://lwn.net/Articles/343924/) have been using dash as the default shell
> and And
Dne 2.10.2014 v 08:33 Lennart Poettering napsal(a):
On Wed, 01.10.14 22:39, Rahul Sundaram (methe...@gmail.com) wrote:
Hi
Is it worth considering using Dash as the default (non-interactive) shell
in Fedora? Other distributions including Ubuntu and Debian (
https://lwn.net/Articles/343924/) ha
On 2 October 2014 07:33, Lennart Poettering wrote:
> On Wed, 01.10.14 22:39, Rahul Sundaram (methe...@gmail.com) wrote:
>
>> Hi
>>
>> Is it worth considering using Dash as the default (non-interactive) shell
>> in Fedora? Other distributions including Ubuntu and Debian (
>> https://lwn.net/Articl
On Thu, Oct 02, 2014 at 08:33:23AM +0200, Lennart Poettering wrote:
> On Wed, 01.10.14 22:39, Rahul Sundaram (methe...@gmail.com) wrote:
>
> > Hi
> >
> > Is it worth considering using Dash as the default (non-interactive) shell
> > in Fedora? Other distributions including Ubuntu and Debian (
> >
On 10/02/2014 08:42 AM, Lennart Poettering wrote:
On Wed, 01.10.14 22:19, Chris Adams (li...@cmadams.net) wrote:
One thing that might be a good topic for consideration: is there a
reasonable way to allow different implementations to take the /bin/sh
symlink? Could this be handled through the a
On 10/02/2014 08:33 AM, Lennart Poettering wrote:
If you change /bin/sh to dash, then you'll have to map two shell
binaries into memory (since the login shell is going to stay on bash),
hence the resource usage grows.
The login shell is a per-user configurable setting, thus the memory
resulti
On Wed, 01.10.14 22:19, Chris Adams (li...@cmadams.net) wrote:
> One thing that might be a good topic for consideration: is there a
> reasonable way to allow different implementations to take the /bin/sh
> symlink? Could this be handled through the alternatives system, so that
> admins could choo
On Wed, 01.10.14 22:39, Rahul Sundaram (methe...@gmail.com) wrote:
> Hi
>
> Is it worth considering using Dash as the default (non-interactive) shell
> in Fedora? Other distributions including Ubuntu and Debian (
> https://lwn.net/Articles/343924/) have been using dash as the default shell
> and
Hi,
On Thu, Oct 2, 2014 at 8:49 AM, Chris Adams wrote:
> Once upon a time, Rahul Sundaram said:
>> Is it worth considering using Dash as the default (non-interactive) shell
>> in Fedora? Other distributions including Ubuntu and Debian (
>> https://lwn.net/Articles/343924/) have been using dash
Once upon a time, Rahul Sundaram said:
> Is it worth considering using Dash as the default (non-interactive) shell
> in Fedora? Other distributions including Ubuntu and Debian (
> https://lwn.net/Articles/343924/) have been using dash as the default shell
> and Android uses mksh. While this appe
Hi
Is it worth considering using Dash as the default (non-interactive) shell
in Fedora? Other distributions including Ubuntu and Debian (
https://lwn.net/Articles/343924/) have been using dash as the default shell
and Android uses mksh. While this appears to have been done primary to
increase bo
100 matches
Mail list logo
