On Thu, 15 Mar 2012 13:48:47 +0100, Stephan Seitz
stse+deb...@fsing.rootsland.net wrote:
If I want „cool” Linux things, then I don’t use a distribution
which is proud to be a cross-platform distribution.
Amen.
Greetings
Marc
--
-- !! No courtesy copies,
On Wed, 14 Mar 2012 14:57:45 +0100, Josselin Mouette j...@debian.org
wrote:
Le mercredi 07 mars 2012 à 07:43 +0100, Marc Haber a écrit :
The differences between systemd and openssh are that core OpenSSH does
not work on our main architecture, and that there is an active
non-Debian upstream for
On Wed, 14 Mar 2012 14:59:02 +0100, Josselin Mouette j...@debian.org
wrote:
Le lundi 05 mars 2012 à 12:11 +0100, Marc Haber a écrit :
The migration to udev didn't cause double work for daemon maintainers.
Excuse me?
Having to support both udev and HAL just for the sake of Hurd and
kFreeBSD
Le jeudi 15 mars 2012 à 12:48 +0100, Marc Haber a écrit :
I maintain multiple daemon packages in Debian and was never forced to
do double work.
Good for you. But do not assume this is everyone’s case.
When it starts to be the case because kFreeBSD doesn’t have a modern
init system available,
On Thu, Mar 15, 2012 at 01:24:40PM +0100, Josselin Mouette wrote:
When it starts to be the case because kFreeBSD doesn’t have a modern
init system available, will you reconsider?
If I don’t want to support it, I will reconsider, if I will stay in
Debian, because Debian is *not* a Linux-only
On Mar 15, Stephan Seitz stse+deb...@fsing.rootsland.net wrote:
Okay, I am not a DD,
This pretty much explains why you are not qualified to partecipate to
this discussion.
--
ciao,
Marco
signature.asc
Description: Digital signature
On Thu, Mar 15, 2012 at 02:10:29PM +0100, Marco d'Itri wrote:
On Mar 15, Stephan Seitz stse+deb...@fsing.rootsland.net wrote:
Okay, I am not a DD,
This pretty much explains why you are not qualified to partecipate to
this discussion.
You do not seem to be interested in having users, do you?
On 03/15/2012 01:24 PM, Josselin Mouette wrote:
Le jeudi 15 mars 2012 à 12:48 +0100, Marc Haber a écrit :
I maintain multiple daemon packages in Debian and was never forced to
do double work.
Good for you. But do not assume this is everyone’s case.
When it starts to be the case because
* Marco d'Itri m...@linux.it [2012-03-15 14:11]:
On Mar 15, Stephan Seitz stse+deb...@fsing.rootsland.net wrote:
Okay, I am not a DD,
This pretty much explains why you are not qualified to partecipate to
this discussion.
Let me quote section 4 first sentence of the social contract: We
On Mar 15, Martin Wuertele m...@debian.org wrote:
Let me quote section 4 first sentence of the social contract: We will
be guided by the needs of our users and the free software community..
This is correct, and it is why we should work to solve the problems of
the platform which has over 1000
On Thu, 2012-03-15 at 13:48 +0100, Stephan Seitz wrote:
On Thu, Mar 15, 2012 at 01:24:40PM +0100, Josselin Mouette wrote:
When it starts to be the case because kFreeBSD doesn’t have a modern
init system available, will you reconsider?
If I don’t want to support it, I will reconsider, if I
Le mercredi 07 mars 2012 à 07:43 +0100, Marc Haber a écrit :
The differences between systemd and openssh are that core OpenSSH does
not work on our main architecture, and that there is an active
non-Debian upstream for Portable OpenSSH. If there were something like
portable systemd, I guess
Le lundi 05 mars 2012 à 12:11 +0100, Marc Haber a écrit :
The migration to udev didn't cause double work for daemon maintainers.
Excuse me?
Having to support both udev and HAL just for the sake of Hurd and
kFreeBSD *is* some additional work for many packages.
--
.''`. Josselin Mouette
On Tue, Feb 28, 2012 at 07:18:51PM +0100, Christoph Egger wrote:
Uoti Urpala uoti.urp...@pp1.inet.fi writes:
I think it's quite arrogant of BSD users to expect others to work to
support their systems.
There's qute a difference between parts of debian expecting upstream to
do the work
On Sat, Feb 25, 2012 at 12:08:51AM +0100, Svante Signell wrote:
I think the fundamental problem is having kFreeBSD in Debian. It's too
much extra work and problems for limited benefit to a small number of
people. Holding things hostage with you have to make this work on
kFreeBSD too or it
On Tue, 6 Mar 2012 10:01:10 +, Jon Dowland j...@debian.org
wrote:
Are we asking different standards from systemd
than we expect from core openssh?
The differences between systemd and openssh are that core OpenSSH does
not work on our main architecture, and that there is an active
non-Debian
On Sun, Mar 04, 2012 at 09:12:32AM +0100, Marc Haber wrote:
There is a different between I don't care about portability and I
won't accept any patches that are only useful on non-Linux platforms.
The former could be remedied by submitting documented and maintained
patches, which saves the
On Mon, 5 Mar 2012 10:14:04 +0200, Riku Voipio riku.voi...@iki.fi
wrote:
On Sun, Mar 04, 2012 at 09:12:32AM +0100, Marc Haber wrote:
There is a different between I don't care about portability and I
won't accept any patches that are only useful on non-Linux platforms.
The former could be
On Fri, 24 Feb 2012 21:09:36 +0200, Uoti Urpala
uoti.urp...@pp1.inet.fi wrote:
Guillem Jover wrote:
While upstreams are obviously entitled to not care at *all* about
portability for their pet projects (at the risk of being either ignored
or forked, I guess), trying to push so hard for the
On Sun, Feb 26, 2012 at 09:00:07PM +0100, Svante Signell wrote:
[snip]
The main question is: For who's interest should Debian exist, the
upstream authors, the Debian maintainers or the users? My vote is on the
latter :)
I think few argue against Debian being for the users. But the question
Is it possible to implement the linux-only feathers that systemd needs?
On Sun, Mar 4, 2012 at 6:20 PM, David Weinehall t...@debian.org wrote:
On Sun, Feb 26, 2012 at 09:00:07PM +0100, Svante Signell wrote:
[snip]
The main question is: For who's interest should Debian exist, the
upstream
Uoti Urpala uoti.urp...@pp1.inet.fi writes:
I think it's quite arrogant of BSD users to expect others to work to
support their systems.
There's qute a difference between parts of debian expecting upstream to
do the work and upstream hostily denying existing patches I'd say
Regards
On Feb 26, Goswin von Brederlow goswin-...@web.de wrote:
By that reasonsing we should not support bsd, hurd, mips, arm, ppc,
ia64, s390 either. Hell lets drop i386 too.
Indeed. The reason we support niche architectures and toy ports is that
some people are interested in doing the work, and
* Uoti Urpala uoti.urp...@pp1.inet.fi [120226 20:20]:
If someone complained about a nontrivial s390-specific problem in a
context where I was upstream, I'd likely ignore him. In the Debian
context, people other than porters should not be obligated to do
significant work to resolve problems
Bernhard R. Link wrote:
While there might be some problems originating from some architecture,
but most problems you will see and people claim to be problems specific
to fringe architectures are actual bugs in the program you just do not
*yet* see on your usual pet architectures. And some more
Uoti Urpala uoti.urp...@pp1.inet.fi writes:
Bernhard R. Link wrote:
Imagine how long amd64 would have taken, if people had not had years
to fix all those 64 bit bugs on alpha first (Which never really got
a mainstream architecture and where it was used was quite server-only.
Who would have
Uoti Urpala uoti.urp...@pp1.inet.fi writes:
I think it's quite arrogant of BSD users to expect others to work to
support their systems. The BSD userbase is small enough that most
projects have alternative things to work on that help a lot more people
than BSD support would. Trying to support
On Sun, 2012-02-26 at 17:36 +0100, Goswin von Brederlow wrote:
Uoti Urpala uoti.urp...@pp1.inet.fi writes:
I think it's quite arrogant of BSD users to expect others to work to
support their systems. The BSD userbase is small enough that most
projects have alternative things to work on
On Sun, 2012-02-26 at 21:03 +0200, Uoti Urpala wrote:
On Sun, 2012-02-26 at 17:36 +0100, Goswin von Brederlow wrote:
Uoti Urpala uoti.urp...@pp1.inet.fi writes:
I don't think it's an accident that this discussion came up in
the context of kFreeBSD. Extra hardware architectures typically
On Mon, Feb 27, 2012 at 4:00 AM, Svante Signell
svante.sign...@telia.com wrote:
On Sun, 2012-02-26 at 21:03 +0200, Uoti Urpala wrote:
On Sun, 2012-02-26 at 17:36 +0100, Goswin von Brederlow wrote:
Uoti Urpala uoti.urp...@pp1.inet.fi writes:
I don't think it's an accident that this discussion
[ Sending this late reply now, which I had around as a draft, but with
the latest incarnation of this debate it's become relevant again. ]
Hi!
On the other kernels lack of features I'll just point to the
“Functionality Equivalence” section in the Porting Guidelines draft I've
been preparing at
Guillem Jover wrote:
On the other kernels lack of features I'll just point to the
“Functionality Equivalence” section in the Porting Guidelines draft I've
been preparing at http://www.hadrons.org/~guillem/debian/ports/porting.
Most of the features listed as required for systemd are either
On Fri, 2012-02-24 at 21:09 +0200, Uoti Urpala wrote:
Guillem Jover wrote:
...
I think it's quite arrogant of BSD users to expect others to work to
support their systems. The BSD userbase is small enough that most
projects have alternative things to work on that help a lot more people
than
[Satoru KURASHIKI]
I don't care either of which policy (daemons should start/stop as
its default), but It would be better that sysadmins are able to
choose that default (in global setting somewhere like init.conf),
and each package's /etc/default/* will override that.
This sound like an
On Thu, Aug 04, 2011 at 07:41:29AM +0200, Thibaut Paumard wrote:
Hi,
Le 03/08/11 17:23, Wouter Verhelst a écrit :
On Mon, Aug 01, 2011 at 03:17:51PM +0600, Andrey Rahmatullin wrote:
On Sun, Jul 31, 2011 at 08:27:04PM +, Clint Adams wrote:
On Sun, Jul 31, 2011 at 05:38:43PM +0600,
On Fri, Aug 05, 2011 at 07:35:49PM +0200, Wouter Verhelst wrote:
If you do want it started, that means you need to install it first. Then
it makes very much sense it is started automatically.
Logical fallacy: run implies install, but install doesn't always
mean run.
--
WBR, wRAR
On Fri, Aug 05, 2011 at 11:52:22PM +0600, Andrey Rahmatullin wrote:
On Fri, Aug 05, 2011 at 07:35:49PM +0200, Wouter Verhelst wrote:
If you do want it started, that means you need to install it first. Then
it makes very much sense it is started automatically.
Logical fallacy: run implies
On Fri, Aug 05, 2011 at 07:12:58PM +0100, Lars Wirzenius wrote:
If you do want it started, that means you need to install it first. Then
it makes very much sense it is started automatically.
Logical fallacy: run implies install, but install doesn't always
mean run.
While that is true,
Lars Wirzenius l...@liw.fi writes:
Anyone wanting a change to status quo (easy-but-secure) should
probably make the tools to allow a sysadmin to switch to
secure-but-easy easily. A patch to update-rc.d to allow overriding
My policy asks me what to do with new services:
On Sat, Aug 06, 2011 at 12:27:43AM +0600, Andrey Rahmatullin wrote:
On Fri, Aug 05, 2011 at 07:12:58PM +0100, Lars Wirzenius wrote:
If you do want it started, that means you need to install it first. Then
it makes very much sense it is started automatically.
Logical fallacy: run
On Friday, August 05, 2011 02:36:13 PM, Lars Wirzenius wrote:
On Sat, Aug 06, 2011 at 12:27:43AM +0600, Andrey Rahmatullin wrote:
On Fri, Aug 05, 2011 at 07:12:58PM +0100, Lars Wirzenius wrote:
If you do want it started, that means you need to install it first.
Then it makes very much
* Thibaut Paumard paum...@users.sourceforge.net [2011-08-04 07:43]:
I don't agree. When I install Debian on a laptop or workstation, I only
want what I need, and most of the time I don't want a SSH or FTP server.
But the day I need it, I install it and I want to use it right away to
connect
On Wed, 3 Aug 2011 00:30:48 + (UTC), Uoti Urpala
uoti.urp...@pp1.inet.fi wrote:
kFreeBSD support is useful for only few people
kFreeBSD allows me to have ZFS with a Userland that I am familiar
with. I'd happily keep this, even if it means not having systemd.
Greetings
Marc
--
hi,
On Mon, Aug 1, 2011 at 7:14 PM, Marco d'Itri m...@linux.it wrote:
When I install a package I want to actually use it.
A better security policy is to not install by default useless packages.
There is a case which I want to install a package and other package
will control their process
On 2011-08-02, Marco d'Itri m...@linux.it wrote:
On Aug 02, Dmitry Nezhevenko d...@dion.org.ua wrote:
Another example is dovecot-imapd. It's possible to use it in
preauthenticated mode. In such case no system-wide daemon is required and
mail client should just start imapd and talk with it
On Mon, Aug 01, 2011 at 03:17:51PM +0600, Andrey Rahmatullin wrote:
On Sun, Jul 31, 2011 at 08:27:04PM +, Clint Adams wrote:
On Sun, Jul 31, 2011 at 05:38:43PM +0600, Andrey Rahmatullin wrote:
I would be glad if all services (at least network-enabled or especially
insecure for other
Hi,
Le 03/08/11 17:23, Wouter Verhelst a écrit :
On Mon, Aug 01, 2011 at 03:17:51PM +0600, Andrey Rahmatullin wrote:
On Sun, Jul 31, 2011 at 08:27:04PM +, Clint Adams wrote:
On Sun, Jul 31, 2011 at 05:38:43PM +0600, Andrey Rahmatullin wrote:
I would be glad if all services (at least
OoO Pendant le temps de midi du lundi 01 août 2011, vers 12:47,
m...@linux.it (Marco d'Itri) disait :
If a package with the default config listens on external ifaces or does
other potentially insecure things (or maybe changes the system state in
some other undesirable way), the
On Tue, Aug 02, 2011 at 08:37:03AM +0200, Vincent Bernat wrote:
Or have a firewall configured.
A (properly configured) firewall¹ might prevent *inbound* service abuse, but
there's always a potential for a mis- or un-configured service to cause
problems on a network (*outbound* service abuse²): a
On Mon, Aug 01, 2011 at 12:14:31PM +0200, Marco d'Itri wrote:
Making the do not start by default policy default for the distro should
improve out-of-box security.
When I install a package I want to actually use it.
A better security policy is to not install by default useless packages.
On Aug 02, Dmitry Nezhevenko d...@dion.org.ua wrote:
What is use?
The maintainers decides what are the prevalent use cases of the package
and try to use defaults which are appropriate for the largest number of
users.
For example rsync package provides both rsync client and
rsync daemon. Both
Jon Dowland writes:
It completely predates Debian releasing non-Linux
kernels and is not mentioned in the social contract. That some
people feel it justifies (or even mandates) non-Linux kernels in
Debian is a retcon. pf, ZFS; these are valid reasons stated that
support kFreeBSD. I
Ian Jackson ijackson at chiark.greenend.org.uk writes:
Debian has a long history of trying to make it possible to use Debian
for as many purposes as we can, even when that means that the system
has to be more complicated, or even when it means Debian has to be
less perfectly suited to some
On Sun, Jul 31, 2011 at 08:27:04PM +, Clint Adams wrote:
On Sun, Jul 31, 2011 at 05:38:43PM +0600, Andrey Rahmatullin wrote:
I would be glad if all services (at least network-enabled or especially
insecure for other reasons) didn't start by default.
Maybe everyone would be happy if there
On Aug 01, Andrey Rahmatullin w...@wrar.name wrote:
On Sun, Jul 31, 2011 at 08:27:04PM +, Clint Adams wrote:
On Sun, Jul 31, 2011 at 05:38:43PM +0600, Andrey Rahmatullin wrote:
I would be glad if all services (at least network-enabled or especially
insecure for other reasons) didn't
On Mon, Aug 01, 2011 at 12:14:31PM +0200, Marco d'Itri wrote:
I would be glad if all services (at least network-enabled or especially
insecure for other reasons) didn't start by default.
Maybe everyone would be happy if there were a central place to set
the administrator's preferred
On Sun, Jul 24, 2011 at 10:52:13PM +0100, Simon McVittie wrote:
even init.d has a documented (and what's
more, actually *working*) implementation of not starting daemons at
boot. It's called 'remove the *** symlink'.
If you remove them, they'll be recreated by the next upgrade; the
On Aug 01, Andrey Rahmatullin w...@wrar.name wrote:
If a package with the default config listens on external ifaces or does
other potentially insecure things (or maybe changes the system state in
some other undesirable way), the administrator may want to change its
config before the first
On Sun, Jul 31, 2011 at 08:27:04PM +, Clint Adams wrote:
I would be glad if all services (at least network-enabled or especially
insecure for other reasons) didn't start by default.
Maybe everyone would be happy if there were a central place to set
the administrator's preferred policy.
On Mon, 2011-08-01 at 16:49 +0600, Andrey Rahmatullin wrote:
On Sun, Jul 24, 2011 at 10:52:13PM +0100, Simon McVittie wrote:
even init.d has a documented (and what's
more, actually *working*) implementation of not starting daemons at
boot. It's called 'remove the *** symlink'.
If
On Mon, 2011-08-01 at 17:14 +0600, Andrey Rahmatullin wrote:
On Sun, Jul 31, 2011 at 08:27:04PM +, Clint Adams wrote:
I would be glad if all services (at least network-enabled or especially
insecure for other reasons) didn't start by default.
Maybe everyone would be happy if there
On Mon, Aug 01, 2011 at 05:59:45PM +0100, Adam D. Barratt wrote:
I would be glad if all services (at least network-enabled or especially
insecure for other reasons) didn't start by default.
Maybe everyone would be happy if there were a central place to set
the administrator's
On Mon, Jul 25, 2011 at 11:26:23AM +0100, Roger Leigh wrote:
Do we actually have a standardised interface that can disable a service
and then reenable it so that it is in exactly the same state as before
it was disabled, without requiring black magic and/or prior knowledge
of the correct
On Mon, Jul 25, 2011 at 05:04:21PM +0200, Wouter Verhelst wrote:
Having said that, I do agree with you that it could benefit from either
better documentation, or a command for system admins to use which would
enable or disable initscripts. RedHat (and similars) have 'chkconfig'
which does
On Sun, Jul 24, 2011 at 10:20:45PM +0200, Wouter Verhelst wrote:
That this is not particularly useful is not specific to any init
implementation. I hate 'ENABLED=' configuration options with a passion.
They do not make *any* sense, even init.d has a documented (and what's
They do in
On Sun, Jul 31, 2011 at 05:38:43PM +0600, Andrey Rahmatullin wrote:
I would be glad if all services (at least network-enabled or especially
insecure for other reasons) didn't start by default.
Maybe everyone would be happy if there were a central place to set
the administrator's preferred
On Thu, Jul 21, 2011 at 22:44:55 +0200, Marc Haber wrote:
[...]
Please don't get me wrong: I like the ideas behind systemd, but I need
some more input to decide whether it's actually as flexible as an init
script.
IMHO the flexibility of init scripts was often abused to do things
which
* Simon McVittie (s...@debian.org) [110724 23:52]:
On Sun, 24 Jul 2011 at 21:59:40 +0200, Wouter Verhelst wrote:
even init.d has a documented (and what's
more, actually *working*) implementation of not starting daemons at
boot. It's called 'remove the *** symlink'.
If you remove
On Sun, Jul 24, 2011 at 10:16:15PM +0200, Stephan Seitz wrote:
Editing /etc/runlevel.conf is easy as well. But I still prefer the
good old „exit 0” version. And talking with other people, this seems
to be far easier to remember if they want to revert the change.
The problem with this is that
On Mon, Jul 25, 2011 at 11:41:36AM +0200, Andreas Barth wrote:
* Simon McVittie (s...@debian.org) [110724 23:52]:
On Sun, 24 Jul 2011 at 21:59:40 +0200, Wouter Verhelst wrote:
even init.d has a documented (and what's
more, actually *working*) implementation of not starting daemons at
On Sat, 23 Jul 2011 13:09:02 -0300, Fernando Lemos
fernando...@gmail.com wrote:
The thing you don't seem to get is that systemd uses init files
No need to be rude and to assume stupidity on the other side when one
is just asking innocent questions about what to expect in the next
years.
You're
On Mon, Jul 25, 2011 at 8:57 AM, Marc Haber
mh+debian-de...@zugschlus.de wrote:
On Sat, 23 Jul 2011 13:09:02 -0300, Fernando Lemos
fernando...@gmail.com wrote:
The thing you don't seem to get is that systemd uses init files
No need to be rude and to assume stupidity on the other side when one
On Sun, Jul 24, 2011 at 10:52:13PM +0100, Simon McVittie wrote:
On Sun, 24 Jul 2011 at 21:59:40 +0200, Wouter Verhelst wrote:
even init.d has a documented (and what's
more, actually *working*) implementation of not starting daemons at
boot. It's called 'remove the *** symlink'.
If
On Mon, Jul 25, 2011 at 12:41:59AM +0200, Tollef Fog Heen wrote:
]] Wouter Verhelst
Hi Wouter,
| At any rate, by not wanting to do scripts, you're making life harder for
| yourself, since now you suddenly have to implement everything what
| people have trivially done in shell scripts for
On Fri, Jul 22, 2011 at 05:09:11PM +0200, Michael Biebl wrote:
A lot of those /etc/default files have a ENABLED=YES flags, which are not
particularly useful with systemd, as systemd provides proper mechanisms to
enable/disable services in a convenient way.
That this is not particularly useful
On Sat, Jul 23, 2011 at 01:09:02PM -0300, Fernando Lemos wrote:
On Sat, Jul 23, 2011 at 12:47 PM, Marc Haber
mh+debian-de...@zugschlus.de wrote:
On Thu, 21 Jul 2011 18:12:13 -0300, Fernando Lemos
fernando...@gmail.com wrote:
A more realistic option would be launching a program (or script)
On Sun, Jul 24, 2011 at 09:59:40PM +0200, Wouter Verhelst wrote:
That this is not particularly useful is not specific to any init
implementation. I hate 'ENABLED=' configuration options with a passion.
They do not make *any* sense, even init.d has a documented (and what's
They do in packages
Wouter Verhelst wou...@debian.org writes:
No. systemd wants to throw out init scripts, because they are shell
scripts, and Shell Scripts Are Bad!!!1!! oh noes.
I don't get that impression. Rather, I think both systemd and upstart
want to significantly reduce the involvement of shell scripts
On Sun, Jul 24, 2011 at 10:16:15PM +0200, Stephan Seitz wrote:
On Sun, Jul 24, 2011 at 09:59:40PM +0200, Wouter Verhelst wrote:
That this is not particularly useful is not specific to any init
implementation. I hate 'ENABLED=' configuration options with a passion.
They do not make *any* sense,
On Sun, Jul 24, 2011 at 01:17:50PM -0700, Russ Allbery wrote:
Wouter Verhelst wou...@debian.org writes:
No. systemd wants to throw out init scripts, because they are shell
scripts, and Shell Scripts Are Bad!!!1!! oh noes.
I don't get that impression. Rather, I think both systemd and
Iustin Pop ius...@debian.org writes:
On Sun, Jul 24, 2011 at 01:17:50PM -0700, Russ Allbery wrote:
I don't get that impression. Rather, I think both systemd and upstart
want to significantly reduce the involvement of shell scripts in the
boot process for the same reason that I'd love to have
On Sun, 24 Jul 2011 at 21:59:40 +0200, Wouter Verhelst wrote:
even init.d has a documented (and what's
more, actually *working*) implementation of not starting daemons at
boot. It's called 'remove the *** symlink'.
If you remove them, they'll be recreated by the next upgrade; the right
way
]] Wouter Verhelst
Hi Wouter,
| At any rate, by not wanting to do scripts, you're making life harder for
| yourself, since now you suddenly have to implement everything what
| people have trivially done in shell scripts for years in C. Writing
| flawless C isn't exactly easy either[1], and even
On Thu, 21 Jul 2011 18:12:13 -0300, Fernando Lemos
fernando...@gmail.com wrote:
I believe the systemd way to handle this would be moving the logic
that automatically configures the daemon with flags or additional
instances out of the init script. In the specific case you mention,
perhaps this
On Fri, 22 Jul 2011 14:48:43 +0200, Tollef Fog Heen tfh...@err.no
wrote:
Another would be to ship three systemd units, one being «smtp», one
being «queue runner» a third being «smtp+queue runner» or just generate
the .service file dynamically based on what the admin configures through
debconf.
On Sat, Jul 23, 2011 at 12:47 PM, Marc Haber
mh+debian-de...@zugschlus.de wrote:
On Thu, 21 Jul 2011 18:12:13 -0300, Fernando Lemos
fernando...@gmail.com wrote:
A more realistic option would be launching a program (or script) which
would read a configuration file (containing whatever
On Fri, Jul 22, 2011 at 05:09:11PM +0200, Michael Biebl wrote:
Configuration file for the daemon is /etc/default/rsyslog:
The canonical configuration file for the rsyslog daemon is
/etc/rsyslog.conf.
Yes, but it doesn’t allow you to change start options of the daemon
itself.
include that via
On Sat, Jul 23, 2011 at 4:47 PM, Stephan Seitz
stse+deb...@fsing.rootsland.net wrote:
On Fri, Jul 22, 2011 at 05:09:11PM +0200, Michael Biebl wrote:
Configuration file for the daemon is /etc/default/rsyslog:
The canonical configuration file for the rsyslog daemon is
/etc/rsyslog.conf.
Yes,
]] Stephan Seitz
Hi,
| I don’t know if files in /etc/default are Debian specific ones, but
| sometimes you need to change start parameters of the daemon. One
| example is sasldauth. If you have postfix in a chroot environemnt
| (standard Debian), you need to change the parameter for the named
|
On Thu, Jul 21, 2011 at 11:37:48PM +0200, Josselin Mouette wrote:
Le jeudi 21 juillet 2011 à 20:01 +0200, Stephan Seitz a écrit :
So, since you don’t need it, other people don’t need it either?
No, since I don’t need it, I don’t want to be forced to use it.
You know, there are some who just
Le vendredi 22 juillet 2011 à 09:58 +0200, Stephan Seitz a écrit :
On Thu, Jul 21, 2011 at 11:37:48PM +0200, Josselin Mouette wrote:
Le jeudi 21 juillet 2011 à 20:01 +0200, Stephan Seitz a écrit :
So, since you don’t need it, other people don’t need it either?
No, since I don’t need it, I
On Fri, Jul 22, 2011 at 10:46:54AM +0200, Josselin Mouette wrote:
Le vendredi 22 juillet 2011 à 09:58 +0200, Stephan Seitz a écrit :
So, since you don’t need it, other people don’t need it either?
No, since I don’t need it, I don’t want to be forced to use it.
So you prefer to force your crap
On Fri, Jul 22, 2011 at 10:46:54AM +0200, Josselin Mouette wrote:
If you want a more suitable comparison, supporting two init systems
would be like supporting two packaging formats. It means more work for
all maintainers to support all possible combinations, and it doesn’t
change anything for
On Fri, Jul 22, 2011 at 6:12 AM, Guus Sliepen g...@debian.org wrote:
By the way, we already have the SysV init scripts, so we don't need to do
anything to keep supporting that, while it will take some time before every
package with a daemon has the required systemd scripts in place, I think we
On Fri, Jul 22, 2011 at 9:20 AM, Fernando Lemos fernando...@gmail.com wrote:
On Fri, Jul 22, 2011 at 6:12 AM, Guus Sliepen g...@debian.org wrote:
By the way, we already have the SysV init scripts, so we don't need to do
anything to keep supporting that, while it will take some time before every
]] Robert Millan
| quote
| If portability was made a mandatory requirement for an init system to
| be adopted,
| would the systemd porters be willing to implement everything needed
| to support on non-Linux ports the packages using a non-traditional init
| configuration, in the way they consider
]] Marc Haber
Hi,
| exim4 is one example, and it adds some extra complexity. An exim4
| daemon does two jobs: Running the queue and listening for SMTP.
| Currently, you can configure in /etc/default/exim4 whether you want
| both jobs to be done by the same daemon, two dedicated daemons or only
]] Guus Sliepen
| On Fri, Jul 22, 2011 at 10:46:54AM +0200, Josselin Mouette wrote:
|
| If you want a more suitable comparison, supporting two init systems
| would be like supporting two packaging formats. It means more work for
| all maintainers to support all possible combinations, and it
On Fri, Jul 22, 2011 at 02:59:09PM +0200, Tollef Fog Heen wrote:
| How hard can it be to
| support both sysvinit and systemd? It's just two little files to
| maintain instead of one. We also have/had both .menu and .desktop
| files. Sure, they will be out of sync once in a while, but other
On Fri, 22 Jul 2011, Tollef Fog Heen tfh...@err.no wrote:
Another would be to ship three systemd units, one being «smtp», one
being «queue runner» a third being «smtp+queue runner» or just generate
the .service file dynamically based on what the admin configures through
debconf.
If there were
1 - 100 of 285 matches
Mail list logo
