On 10/02/14 14:55, Jonathan Dowland wrote:
> On 09/02/2014 13:14, Thomas Goirand wrote:
>> Is it too late to fix this as a release goal, so that we get every
>> init script to use /bin/sh?
>
> Whether this is worth the effort or not (and not just *your* effort, the
>
On 09/02/2014 13:14, Thomas Goirand wrote:
> Is it too late to fix this as a release goal, so that we get every
> init script to use /bin/sh?
Whether this is worth the effort or not (and not just *your* effort, the
effort of maintainers of packages with init scripts, even if just to
revi
On Feb 09, Clint Byrum wrote:
> > That's it... So that's a typical case where it should be possible to fix
> > things, and get rid of bash.
> Is that really an important goal to spend our time on?
No. It has never been a goal, there is nothing to "fix" here.
--
ciao,
Marco
signature.asc
Descr
* about which init system to
> >> use, I think it's more productive to try to improve what we have in
> >> packages, so I'd like to talk about that.
> >>
> >> One thing that bothers me is that some of our sysv-rc init.d scripts
> >> aren't
life more easy, and avoid ugly hacks.
why is that a problem for OpenRC?
> Is it too late to fix this as a release goal, so that we get every init
> script to use /bin/sh?
There is nothing like making it a release goal that would result in it
getting magically getting fixed in all packages aut
e have in
>> packages, so I'd like to talk about that.
>>
>> One thing that bothers me is that some of our sysv-rc init.d scripts
>> aren't using /bin/sh as interpreter.
>>
>> For example, on my laptop, the only one that I have is MySQL. Then after
>
>
> One thing that bothers me is that some of our sysv-rc init.d scripts
> aren't using /bin/sh as interpreter.
>
> For example, on my laptop, the only one that I have is MySQL. Then after
> fixing the shebang and running checkbashism, I can only see:
>
On Sun, Feb 9, 2014 at 3:47 PM, Petter Reinholdtsen wrote:
>
> [Thomas Goirand]
>> If possible, I'd like to make a survey of what kind of interpreter
>> packages are using for /etc/init.d scripts. How can I do that? Note
>> that this would make OpenRC maintainer's life more easy, and avoid
>> ugly
do all packages
in one shell one-liner. :)
> Is it too late to fix this as a release goal, so that we get every
> init script to use /bin/sh?
I believe it is too late. I would recommend on focusing on a subset
with the most used packages for Jessie. But that depend on how many
init.d do not
Hi,
While we can discuss during literally *years* about which init system to
use, I think it's more productive to try to improve what we have in
packages, so I'd like to talk about that.
One thing that bothers me is that some of our sysv-rc init.d scripts
aren't using /bin/sh
On Mittwoch, 22. Mai 2013, Ben Hutchings wrote:
> I think you're missing Holger's point: FSF has had great success with
> the GNU project. This is independent of the Hurd kernel.
Yet I'm happy to finally see a Debian GNU/Hurd release. Wow! & Whohooo!
signature.asc
Description: This is a digital
On Wed, May 22, 2013 at 04:01:19PM +0200, Svante Signell wrote:
> On Wed, 2013-05-22 at 13:37 +0200, Holger Levsen wrote:
> > Hi,
> >
> > On Mittwoch, 22. Mai 2013, Dmitrijs Ledkovs wrote:
> > > FSF on the other hand:
> > [...]
> >
> > You forgot their failure with this "gnu unix system" they wer
On Wed, 2013-05-22 at 13:37 +0200, Holger Levsen wrote:
> Hi,
>
> On Mittwoch, 22. Mai 2013, Dmitrijs Ledkovs wrote:
> > FSF on the other hand:
> [...]
>
> You forgot their failure with this "gnu unix system" they were trying to
> build! This also didnt take off - what a bunch of loosers!
It is
On Wed, May 22, 2013 at 01:35:54PM +0200, Wouter Verhelst wrote:
> No, that is *exactly* the point: yes, companies may have different
> objectives, but that doesn't mean they have to use different ways to get
> to those objectives.
>
> A contract is binding, whether one party to the contract is a
Hi,
On Mittwoch, 22. Mai 2013, Dmitrijs Ledkovs wrote:
> FSF on the other hand:
[...]
You forgot their failure with this "gnu unix system" they were trying to
build! This also didnt take off - what a bunch of loosers!
cheers,
Holger
signature.asc
Description: This is a digitally sign
On 22-05-13 13:06, Stefano Zacchiroli wrote:
> On Wed, May 22, 2013 at 10:13:23AM +0100, Dmitrijs Ledkovs wrote:
>> Some produce more open source software than others, and all of these
>> will be ranked differently by each person differently, am I still yet
>> to be screwed by Canonical's projects.
On Wed, May 22, 2013 at 10:13:23AM +0100, Dmitrijs Ledkovs wrote:
> Some produce more open source software than others, and all of these
> will be ranked differently by each person differently, am I still yet
> to be screwed by Canonical's projects. Please correct me if I am
> wrong, but none of Ca
On 22 May 2013 03:32, Paul Tagliamonte wrote:
> On Wed, May 22, 2013 at 01:16:29AM +0100, Dmitrijs Ledkovs wrote:
>> I have signed Canonical's and Python Software Foundation's contributor
>> agreements.
>> But I have no intention to assign copyright to FSF at the moment,
>> given it's past well do
On Wed, May 22, 2013 at 01:16:29AM +0100, Dmitrijs Ledkovs wrote:
> I have signed Canonical's and Python Software Foundation's contributor
> agreements.
> But I have no intention to assign copyright to FSF at the moment,
> given it's past well documented bad practices at doing things for the
> sake
On 13 May 2013 19:14, Russ Allbery wrote:
> Philip Hands writes:
>
>> No matter what the technical merits, the inevitable flame war regarding
>> copyright assignment seems very likely to render upstart a non-starter
>> as an essential element of Debian.
>
> Debian already uses many packages as pa
; > the
> > > part of anyone proposing to change the shell again is to fix those RC bugs
> > > without introducing new ones.
>
> > The system-shell idea fixes axactly those two bugs:
>
> > # dash fails to upgrade if /bin/sh is locally diverted
> > # dash up
On Fri, 17 May 2013 13:42:30 +0200, Holger Levsen
wrote:
>On Freitag, 17. Mai 2013, Marc Haber wrote:
>> We're going to have a TC decision or a GR about this anyway.
>
>why do you think so?
Because I think that a decision of this magnitude should not be taken
by a single developer, not even by M'
still has two outstanding multiply-release-ignored grave bugs as a
> > result of the last transition. A minimum demonstration of competence on the
> > part of anyone proposing to change the shell again is to fix those RC bugs
> > without introducing new ones.
> The system-sh
On 2013-05-07 14:23:47 +, Thorsten Glaser wrote:
> Shells suitable for /bin/sh are currently bash, dash, mksh.
I forgot about that (partly because of workarounds), but due to the
SIGINT problem, I think that *currently*, among these 3 shells, bash
is the most suitable one, and mksh is a
Hi Marc,
On Freitag, 17. Mai 2013, Marc Haber wrote:
> We're going to have a TC decision or a GR about this anyway.
why do you think so?
cheers,
Holger
signature.asc
Description: This is a digitally signed message part.
On Mon, 13 May 2013 02:31:02 +0200, m...@linux.it (Marco d'Itri) wrote:
>Maybe kfreebsd will do, but as I explained at FOSDEM I plan to make udev
>depend on either upstart or systemd.
>I would rather not be the one who will choose which one of them, so
>I hope that we will get to a consensus abou
Joshuah Hurst dixit:
>Solaris 11, OpenSolaris and Illumos use ksh93 as /bin/sh
Yeah, but it’s not eligible for that in Debian, as Debian guarantees
the usability of “local” even for /bin/sh scripts. I wrote about that
already, IIRC even in this thread.
>/usr/bin/sh
Yuk, Solaris abomi
On Tue, May 7, 2013 at 4:23 PM, Thorsten Glaser wrote:
>
> Andreas Beckmann debian.org> writes:
>
> > now might be the right time to start a discussion about release goals
> > for jessie. Here are some points that come into my mind right now (and
>
> * Resolve that
t; thing not driven by me; if there???s enough other people (especially DDs)
> interested in actually doing that it has potential to get taken a bit
> seriously at all; if I???m involved, all bets are off (especially now, I
> guess).
There are two issues you mix here:
1) Using mksh as /
#x27;d like, too.
[...]
>> Using the diversion mechanism to change /bin/sh is highly risky and was
>> never supported.
>
> Actually, dash uses a diversion too, so it was supported pretty well.
Well, no, not really; it causes many problems...
--
This end should point towa
Hi Thorsten
On 11-05-13 20:26, Thorsten Glaser wrote:
> Steve Langasek debian.org> writes:
>
>> This is not a sensible goal. Choice of /bin/sh should *not* be the goal,
>> the goal should be to get a good, fast, minimal, policy-compliant /bin/sh
>> for *everyone*.
o be able to have more than *2* packages provide /bin/sh.
> >
> > > Currently, due to the totaly screwed up way this is done, only dash or
> > > bash can be /bin/sh.
> >
> > This is not a sensible goal. Choice of /bin/sh should *not* be the goal,
> > the goal
nsition. A minimum demonstration of competence on the
> part of anyone proposing to change the shell again is to fix those RC bugs
> without introducing new ones.
The system-shell idea fixes axactly those two bugs:
# dash fails to upgrade if /bin/sh is locally diverted
# dash upgrade breaks
to choose between two /bin/sh shells or two /sbin/init
> > implementations is not.
>
> The shell I can agree with. It is required to provide a POSIX shell,
> so as long as it is fully functional and performs well, just
> picking one and sticking with it is absolutely fine.
You
o be able to have more than *2* packages provide /bin/sh.
> >
> > > Currently, due to the totaly screwed up way this is done, only dash or
> > > bash can be /bin/sh.
> >
> > This is not a sensible goal. Choice of /bin/sh should *not* be the goal,
> > the goal
On Sat, May 11, 2013 at 05:29:45PM +0200, Sven Joachim wrote:
> On 2013-05-11 11:22 +0200, Goswin von Brederlow wrote:
>
> > While that might be of some interest the real goal of the change was
> > to be able to have more than *2* packages provide /bin/sh.
> >
> >
ars ago, Apple shipped zsh as /bin/sh for Mac OS X. It broke a
lot of things at the time, including some of the autotools. I also
tried zsh as /bin/sh, but found that debconf didn't work at all. Don't
get me wrong, I love zsh, but without some serious work, it isn't at all
a viab
Am 15.05.2013 02:12, schrieb Michael Biebl:
> Am 15.05.2013 01:26, schrieb brian m. carlson:
>> On Sat, May 11, 2013 at 10:08:21PM +0200, Josselin Mouette wrote:
>>> This is utter bullshit and you should already know it. Systemd is much
>>> more reliable as a whole than any other implementation. I
Helmut Grohne writes:
> Using the diversion mechanism to change /bin/sh is highly risky and was
> never supported. Even if Debian only supports running dash (or bash) as
> /bin/sh and we ignore problems from broken scripts, there still is the
> breakage resulting from the diversio
Tollef Fog Heen writes:
> ]] "brian m. carlson"
>> It means that it works completely differently from every existing Unix
>> log parser on the planet. syslog is hardly "no formatting at all".
> syslog and other log files isn't structured particularly well.
That's the understatement of the yea
On 05/15/2013 05:52 AM, Vincent Bernat wrote:
> I have still hard time to consider that you absolutely did not mention
> something related to a bootloader.
I believe Phil Hands explained better than I would
what I tried to explain.
On 05/15/2013 05:52 AM, Vincent Bernat wrote:
> Like in the previo
On 05/14/2013 06:07 PM, Philip Hands wrote:
> He missed the fact that you were contrasting one non-crashing init, that
> is capable of restarting dead services, with another non-crashing
> init setup that is not able to do so (without help).
Oh, indeed I missed that point! Thanks Phil.
Thomas
-
ot driven by me; if there’s enough other people (especially DDs)
interested in actually doing that it has potential to get taken a bit
seriously at all; if I’m involved, all bets are off (especially now, I
guess).
> Using the diversion mechanism to change /bin/sh is highly risky and was
> never
On 2013-05-07 14:23:47 +, Thorsten Glaser wrote:
> Shells suitable for /bin/sh are currently bash, dash, mksh.
[...]
> I have no idea whether yash or zsh can be made suitable, but I think
> both could, if the maintainers and possibly upstream are interested.
Though zsh has an
On Sat, May 11, 2013 at 06:26:40PM +, Thorsten Glaser wrote:
> Oh, sorry, I forgot, you work for Canonical (which totally explains some
> of your writings in the other eMail too, which I’m not going to comment
> on). Of course, for *buntu people it’s not about choice.
I think you are totally o
"brian m. carlson" writes:
>> I have no idea why people assume that a binary format means it can only
>> be processed with a special, proprietary tool. Binary simply means what
>> it means, binary and not text which means it's a more stream-lined and
>> machine-readable format as opposed to a tex
"brian m. carlson" writes:
> On Sat, May 11, 2013 at 10:08:21PM +0200, Josselin Mouette wrote:
>> This is utter bullshit and you should already know it. Systemd is much
>> more reliable as a whole than any other implementation. I have yet to
>> see a use case where it is not better.
>
> It is not
Le mardi 14 mai 2013 à 23:26 +, brian m. carlson a écrit :
> For better or for worse, sysvinit provides a lot of modularity. systemd
> provides none of that modularity
Maybe you should read a bit about systemd before saying such nonsense.
The real-world systemd (not the imaginary software yo
On Tue, May 14, 2013 at 08:59:57AM +, Thorsten Glaser wrote:
> Helmut Grohne subdivi.de> writes:
>
> > What are the benefits of using shells other than dash for /bin/sh? (as
>
> Why does dash get special treatment, anyway? It was ???suddenly??? in
> Debian after ha
]] "brian m. carlson"
> On Wed, May 15, 2013 at 02:29:40AM +0200, John Paul Adrian Glaubitz wrote:
> > On 05/15/2013 02:16 AM, Michael Biebl wrote:
> > >Am 15.05.2013 01:26, schrieb brian m. carlson:
> > >>On Sat, May 11, 2013 at 10:08:21PM +0200, Josselin Mouette wrote:
> > >>>This is utter bull
]] "brian m. carlson"
> On Wed, May 15, 2013 at 02:12:10AM +0200, Michael Biebl wrote:
> > Am 15.05.2013 01:26, schrieb brian m. carlson:
> > > On Sat, May 11, 2013 at 10:08:21PM +0200, Josselin Mouette wrote:
> > >> This is utter bullshit and you should already know it. Systemd is much
> > >> mo
On Wed, May 15, 2013 at 02:12:10AM +0200, Michael Biebl wrote:
> Am 15.05.2013 01:26, schrieb brian m. carlson:
> > On Sat, May 11, 2013 at 10:08:21PM +0200, Josselin Mouette wrote:
> >> This is utter bullshit and you should already know it. Systemd is much
> >> more reliable as a whole than any ot
On Wed, May 15, 2013 at 02:29:40AM +0200, John Paul Adrian Glaubitz wrote:
> On 05/15/2013 02:16 AM, Michael Biebl wrote:
> >Am 15.05.2013 01:26, schrieb brian m. carlson:
> >>On Sat, May 11, 2013 at 10:08:21PM +0200, Josselin Mouette wrote:
> >>>This is utter bullshit and you should already know i
> And, when it comes to processing, binary data is actually *easier* to
> process. Everyone who has ever written a text parser themselves will
> agree.
I guess everyone who has used grep, tr, sed and so on will disagree?
--
Salvo Tomaselli
http://web.student.chalmers.se/~saltom/
--
To UNSUBSC
On 05/15/2013 02:16 AM, Michael Biebl wrote:
Am 15.05.2013 01:26, schrieb brian m. carlson:
On Sat, May 11, 2013 at 10:08:21PM +0200, Josselin Mouette wrote:
This is utter bullshit and you should already know it. Systemd is much
more reliable as a whole than any other implementation. I have yet
Am 15.05.2013 01:26, schrieb brian m. carlson:
> On Sat, May 11, 2013 at 10:08:21PM +0200, Josselin Mouette wrote:
>> This is utter bullshit and you should already know it. Systemd is much
>> more reliable as a whole than any other implementation. I have yet to
>> see a use case where it is not bet
Am 15.05.2013 01:26, schrieb brian m. carlson:
> On Sat, May 11, 2013 at 10:08:21PM +0200, Josselin Mouette wrote:
>> This is utter bullshit and you should already know it. Systemd is much
>> more reliable as a whole than any other implementation. I have yet to
>> see a use case where it is not bet
On Sat, May 11, 2013 at 10:08:21PM +0200, Josselin Mouette wrote:
> This is utter bullshit and you should already know it. Systemd is much
> more reliable as a whole than any other implementation. I have yet to
> see a use case where it is not better.
It is not better if you don't want proprietary
❦ 14 mai 2013 11:54 CEST, Thomas Goirand :
>> Yes of course, because a different init system will magically make your
>> other disk bootable.
>
> This is absolutely *NOT* what I said. Nothing in my message
> compares this or that init system. I just replied that when you
> have apache, it's easi
On Tue, May 14, 2013 at 10:03:34AM -0700, Russ Allbery wrote:
> I think that, to convince people that flexibility won't cause stability
> and complexity problems, you're going to need to present a complete and
> fairly bulletproof implementation plan. Given how difficult the bash to
> dash transi
On Tue, May 14, 2013 at 08:59:57AM +, Thorsten Glaser wrote:
> Helmut Grohne subdivi.de> writes:
> > What are the benefits of using shells other than dash for /bin/sh? (as
> Why does dash get special treatment, anyway?
Because /bin/sh is special under Debian policy,
Thorsten Glaser writes:
> Helmut Grohne subdivi.de> writes:
>> What are the benefits of using shells other than dash for /bin/sh? (as
> Why does dash get special treatment, anyway? It was “suddenly“ in
> Debian after having been used in Ubuntu, but… there never was an
>
On Tue, 2013-05-14 at 08:59 +, Thorsten Glaser wrote:
> Helmut Grohne subdivi.de> writes:
>
> > What are the benefits of using shells other than dash for /bin/sh? (as
>
> Why does dash get special treatment, anyway? It was “suddenly“ in
> Debian after having been us
On Sat, May 11, 2013 at 08:44:30PM +0100, Roger Leigh wrote:
> ...
> forcing the rest of the world to conform to our worldview. One
> desktop environment, and an awful one at that, dictating the
> init system we use is a complete farce. Debian is a lot bigger
> than GNOME, and if we have to, I
Josselin Mouette writes:
> Le mardi 14 mai 2013 à 15:28 +0800, Thomas Goirand a écrit :
>> On 05/13/2013 06:05 AM, Josselin Mouette wrote:
>> > Having a rock-stable PID 1 is nice and all, but it doesn’t help you if
>> > something important crashes. On a production server, if apache crashes
>> >
On 05/14/2013 04:51 PM, Josselin Mouette wrote:
> Yes of course, because a different init system will magically make your
> other disk bootable.
This is absolutely *NOT* what I said. Nothing in my message
compares this or that init system. I just replied that when you
have apache, it's easier to r
Helmut Grohne subdivi.de> writes:
> What are the benefits of using shells other than dash for /bin/sh? (as
Why does dash get special treatment, anyway? It was “suddenly“ in
Debian after having been used in Ubuntu, but… there never was an
evaluation of shells.
I still believe the codeb
Le mardi 14 mai 2013 à 15:28 +0800, Thomas Goirand a écrit :
> On 05/13/2013 06:05 AM, Josselin Mouette wrote:
> > Having a rock-stable PID 1 is nice and all, but it doesn’t help you if
> > something important crashes. On a production server, if apache crashes
> > and fails to reload properly beca
On 05/13/2013 06:05 AM, Josselin Mouette wrote:
> Le dimanche 12 mai 2013 à 19:40 +0200, Helmut Grohne a écrit :
>> With all due respect, this might be utter bullshit, but is at least
>> [citation needed]. I have yet to see a failing pid 1 (be that sysv,
>> upstart or systemd). Acquiring data on f
2013/5/14 Игорь Пашев :
> 2013/5/13 Philipp Kern :
>> On Mon, May 13, 2013 at 08:46:23AM +0100, Roger Leigh wrote:
>>> There is no need for udev to be dependent upon a specific init
>>> system, other than laziness.
>>
>> Except if you want to receive device plug events as triggers to start
>> up /
2013/5/13 Philipp Kern :
> On Mon, May 13, 2013 at 08:46:23AM +0100, Roger Leigh wrote:
>> There is no need for udev to be dependent upon a specific init
>> system, other than laziness.
>
> Except if you want to receive device plug events as triggers to start
> up / shut down services. The separati
On Mon, May 13, 2013 at 08:46:23AM +0100, Roger Leigh wrote:
> There is no need for udev to be dependent upon a specific init
> system, other than laziness.
Except if you want to receive device plug events as triggers to start
up / shut down services. The separation then gets quite blurry with
who
On Mon, May 13, 2013 at 11:14:58AM -0700, Russ Allbery wrote:
> When evaluating relative merits, I think the relative sizes of the
> development communities and the integration with other important
> subsystems (like desktop environments) are more relevant reasons to be
> concerned about upstart c
Philip Hands writes:
> No matter what the technical merits, the inevitable flame war regarding
> copyright assignment seems very likely to render upstart a non-starter
> as an essential element of Debian.
Debian already uses many packages as part of its essential set that
require copyright assig
On May 13, Philip Hands wrote:
> No matter what the technical merits, the inevitable flame war regarding
> copyright assignment seems very likely to render upstart a non-starter
> as an essential element of Debian.
I think that this is a reasonable element to consider in our decision
process.
-
On May 13, "gustavo panizzo " wrote:
> On 2013-05-12 21:31, m...@linux.it wrote:
> >Maybe kfreebsd will do, but as I explained at FOSDEM I plan to
> >make udev depend on either upstart or systemd.
> do you have a link to a presentation, blog post, or whatever
> explaining the rationale behind thi
On Mon, May 13, 2013 at 12:05:59AM +0200, Josselin Mouette wrote:
> Having a rock-stable PID 1 is nice and all, but it doesn???t help you if
> something important crashes. On a production server, if apache crashes
> and fails to reload properly because the scripts don???t get the ordering
> right,
On 2013-05-12 21:31, m...@linux.it wrote:
Maybe kfreebsd will do, but as I explained at FOSDEM I plan to make
udev
depend on either upstart or systemd.
do you have a link to a presentation, blog post, or whatever explaining
the rationale behind this?
i didn't found anything on FOSDEM website
Marco d'Itri writes:
> On May 13, Holger Levsen wrote:
>
>> actually, while it has been brought up as a theoretical/wrong argument, that
>> we cannot switch our linux installation ship with $this init system, while
>> the
>> kfreebsd port uses $that init system, I'd say nobody is seriously sa
On Mon, May 13, 2013 at 02:31:02AM +0200, Marco d'Itri wrote:
> On May 13, Holger Levsen wrote:
>
> > actually, while it has been brought up as a theoretical/wrong argument,
> > that
> > we cannot switch our linux installation ship with $this init system, while
> > the
> > kfreebsd port uses
customize your user interface, but I don't think it makes
> sense to be able to customize a core component like the init daemon.
AFAICT the discussion is about /bin/sh, not about the login shell. For
most users it will not make much difference which of dash, bash, etc.
provides /bin/sh
❦ 11 mai 2013 22:08 CEST, Josselin Mouette :
>> I can't agree with having no choice with regard to init. We aren't
>> all using GNOME, and Debian is used in an extremely diverse set of
>> fields for a multitude of different purposes. No one init is
>> appropriate for all of these applications.
On May 13, Holger Levsen wrote:
> actually, while it has been brought up as a theoretical/wrong argument, that
> we cannot switch our linux installation ship with $this init system, while
> the
> kfreebsd port uses $that init system, I'd say nobody is seriously saying this
> now. We will supp
Hi,
On Montag, 13. Mai 2013, Josselin Mouette wrote:
> I was all for kfreebsd when it was proposed, but now that it exists and
> nobody uses it, I am appalled at the idea of using it as an excuse to
> stop making improvements to the linux ports.
actually, while it has been brought up as a theoret
Le dimanche 12 mai 2013 à 19:40 +0200, Helmut Grohne a écrit :
> With all due respect, this might be utter bullshit, but is at least
> [citation needed]. I have yet to see a failing pid 1 (be that sysv,
> upstart or systemd). Acquiring data on failure modes of any of those
> systems appears like a
2013/5/12 John Paul Adrian Glaubitz :
> Honestly, you simply can't expect every single package in Debian to run on
> any of the supported kernels. If systemd profits from the use of
> Linux-specific kernel features, which is a good thing in my humble opinion
> because Linux has many very advanced a
re one outperforms the other.
No, sysvinit has always been slower for me than systemd. The first thing
I do after installing a new Debian box is replacing sysvinit with
systemd. It's like using Internet Explorer to download Firefox on Windows.
Let me therefore direct a question to those i
where one outperforms the other.
And this is where choice makes sense IF the benefits outweigh its costs.
Unfortunately that if is a very tough question.
Let me therefore direct a question to those in favour of a switchable
/bin/sh:
What are the benefits of using shells other than dash for /bin/sh?
On Du, 12 mai 13, 23:12:48, Thomas Goirand wrote:
> Which is very different from being able to select, in d-i,
> what desktop you want (for example using the netinst CD).
This is already possible (from the boot menu).
Kind regards,
Andrei
--
http://wiki.debian.org/FAQsFromDebianUser
Offtopic dis
On 05/12/2013 09:56 PM, Joerg Jaspert wrote:
> Not sure when you did it last (or rleigh or zigo) - but: Take a look at
> what CDs we over.
>
> What you hope - we already do. We have CDs which default to KDE, XFCE or
> LXDE for those who dislike the GNOME feature-removitis.
Which is very different f
On 13209 March 1977, Marc Haber wrote:
>>Like for everything in Debian, this is bound to someone killing
>>the concept of a default Desktop. It is indeed a shame that
>>nobody worked on that.
> What is planned to do so? I surely hope that we don't end up building
> Kebian, Gebian and Xebian Images,
On Sun, 12 May 2013 10:40:53 +0800, Thomas Goirand
wrote:
>On 05/12/2013 03:44 AM, Roger Leigh wrote:
>> We all saw where GNOME took use with their lack of choice: an
>> unusable trainwreck. It's a disgrace that this shipped as the
>> default desktop for wheezy, it really is.
>
>Like for everythi
On 05/12/2013 03:44 AM, Roger Leigh wrote:
> We all saw where GNOME took use with their lack of choice: an
> unusable trainwreck. It's a disgrace that this shipped as the
> default desktop for wheezy, it really is.
Like for everything in Debian, this is bound to someone killing
the concept of a d
+++ Steve Langasek [2013-05-11 09:33 -0700]:
> On Sat, May 11, 2013 at 11:22:10AM +0200, Goswin von Brederlow wrote:
> > While that might be of some interest the real goal of the change was
> > to be able to have more than *2* packages provide /bin/sh.
>
> > Currently, d
Thorsten Glaser writes:
> Steve Langasek debian.org> writes:
>
>> This is not a sensible goal. Choice of /bin/sh should *not* be the goal,
>> the goal should be to get a good, fast, minimal, policy-compliant /bin/sh
>> for *everyone*.
>
> Sure. We just disagree
On Sat, 2013-05-11 at 22:08 +0200, Josselin Mouette wrote:
> Le samedi 11 mai 2013 à 20:44 +0100, Roger Leigh a écrit :
> > I can't agree with having no choice with regard to init. We aren't
> > all using GNOME, and Debian is used in an extremely diverse set of
> > fields for a multitude of diffe
On Sat, May 11, 2013 at 8:08 PM, Josselin Mouette wrote:
> Le samedi 11 mai 2013 à 20:44 +0100, Roger Leigh a écrit :
>> We all saw where GNOME took use with their lack of choice: an
>> unusable trainwreck.
>
> This is your opinion. There are other users who happen to value features
> over configu
>Debian is about Free Software.
Actually, about Free Users, isn't it?
http://mako.cc/copyrighteous/freedom-for-users-not-for-software
bye,
//mirabilos
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.or
2013/5/12 Josselin Mouette :
> GNOME depends on a working glibc, too. Does it dictate the C library?
Yes. Portability still makes sense. Portability is a part of the word
"Free" in "Free Software".
Debian is about Free Software.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.or
Le samedi 11 mai 2013 à 20:44 +0100, Roger Leigh a écrit :
> I can't agree with having no choice with regard to init. We aren't
> all using GNOME, and Debian is used in an extremely diverse set of
> fields for a multitude of different purposes. No one init is
> appropriate for all of these appli
1 - 100 of 418 matches
Mail list logo
