On Wed, 26 May 2010, Bastien Nocera wrote:
> Not very long multiplied by cold caches, and memory allocations and
> frees, etc. The problem isn't that awk is launched, is that it's
> launched a 100 times along with grep, cut, whatever kind of sticks and
> strings you can get in shell text processin
On Tue, 25 May 2010, Simo Sorce wrote:
> I'd like to remember that there are *many* upstreams are going to
> resistant to this change. A lot of upstream projects need to be
> compatible to a lot of Linux and Unix systems, even old ones, so
> before they move they want guarantee that this is rea
On Wed, Jun 02, 2010 at 11:25:56AM +0200, Roberto Ragusa wrote:
> Kevin Kofler wrote:
> > Roberto Ragusa wrote:
> >> In recent times some stupid (IMHO) ideas have been adopted in Linux
> >> just to copy what others do. Just as examples: the control of desktop
> >> widgets in KDE4 (functional GUI el
Lennart Poettering wrote:
> On Wed, 26.05.10 22:06, Björn Persson (bj...@rombobjörn.se) wrote:
> > This suggests to me that environment variables isn't the right way to do
> > this. Environment variables are good for parameters that should be
> > available to many processes. Command line parameters
Kevin Kofler wrote:
> Roberto Ragusa wrote:
>> In recent times some stupid (IMHO) ideas have been adopted in Linux
>> just to copy what others do. Just as examples: the control of desktop
>> widgets in KDE4 (functional GUI elements modified by a mouse-over???),
>
> I only know of 2 plasmoids trigg
On Wed, 2010-06-02 at 07:58 +0200, Kevin Kofler wrote:
> Dave Airlie wrote:
> > So does gdm use multiple X servers, I wasn't aware there was any other
> > way.
>
> So what does it do exactly? Spawn a new X server on the same vterm? Or on a
> different vterm? What KDM does is to spawn a new X serv
Matt McCutchen wrote:
> Please be careful not to take Lennart's remark out of context. A server
> takes longer /than a desktop/ since it doesn't take full advantage of
> systemd; it doesn't take longer than without systemd, because presumably
> the SysV init emulation doesn't have a significant pe
Dave Airlie wrote:
> So does gdm use multiple X servers, I wasn't aware there was any other
> way.
So what does it do exactly? Spawn a new X server on the same vterm? Or on a
different vterm? What KDM does is to spawn a new X server on a different
vterm.
Kevin Kofler
--
devel mailing
On Tue, Jun 01, 2010 at 09:58:37PM +0200, Roberto Ragusa wrote:
> Lennart Poettering wrote:
> > On Sat, 29.05.10 19:48, Roberto Ragusa (m...@robertoragusa.it) wrote:
> >> Well, I really do not want to flame anyone, but please consider that
> >> the guy proposing the change already gave us pulseaudi
On Wed, 2010-06-02 at 02:33 +0200, Kevin Kofler wrote:
> Roberto Ragusa wrote:
> > In recent times some stupid (IMHO) ideas have been adopted in Linux
> > just to copy what others do. Just as examples: the control of desktop
> > widgets in KDE4 (functional GUI elements modified by a mouse-over???),
On Wed, 2010-06-02 at 02:50 +0200, Kevin Kofler wrote:
> Lennart Poettering wrote:
> > It's OK if a server takes a bit longer to boot.
>
> A longer boot time for your server means more downtime if you need to reboot
> your server for whatever reason.
Please be careful not to take Lennart's remar
Lennart Poettering wrote:
> It's OK if a server takes a bit longer to boot.
A longer boot time for your server means more downtime if you need to reboot
your server for whatever reason.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mai
Roberto Ragusa wrote:
> In recent times some stupid (IMHO) ideas have been adopted in Linux
> just to copy what others do. Just as examples: the control of desktop
> widgets in KDE4 (functional GUI elements modified by a mouse-over???),
I only know of 2 plasmoids triggering actions on mouse-over:
On Tue, 01.06.10 15:25, Bill Nottingham (nott...@redhat.com) wrote:
> Lennart Poettering (mzerq...@0pointer.de) said:
> > > > Requires=basic.target sockets.target dbus.socket
> > > > After=basic.target sockets.target dbus.socket
> > >
> > > What does this goop mean and why is it necessary?
> >
Lennart Poettering wrote:
> On Sat, 29.05.10 19:48, Roberto Ragusa (m...@robertoragusa.it) wrote:
>> Well, I really do not want to flame anyone, but please consider that
>> the guy proposing the change already gave us pulseaudio, which promised the
>> "it will do anything you do now, just easier" f
Lennart Poettering (mzerq...@0pointer.de) said:
> > > Requires=basic.target sockets.target dbus.socket
> > > After=basic.target sockets.target dbus.socket
> >
> > What does this goop mean and why is it necessary?
>
> basic.target encapsulates the early boot process (kinda the same stuff
> rc.sys
On Tue, 01.06.10 05:53, Mike Fedyk (mfe...@mikefedyk.com) wrote:
> On Tue, Jun 1, 2010 at 4:22 AM, Lennart Poettering
> wrote:
> > On Tue, 01.06.10 01:56, Mike Fedyk (mfe...@mikefedyk.com) wrote:
> >
> >> > KillMode=control-group → the entire cgroup is shot down
> >> > KillMode=process-group → o
> What type of cgroup are you using? Does it impede the use of lxc for
> containers? Ie, the cgroup type that systemd needs to be able to be
> nested inside a container in a whole OS virtualization (think VPS /
> Virtual Private Server where each VPS has root in its container).
>
systemd uses a
On Tue, Jun 1, 2010 at 4:22 AM, Lennart Poettering wrote:
> On Tue, 01.06.10 01:56, Mike Fedyk (mfe...@mikefedyk.com) wrote:
>
>> > KillMode=control-group → the entire cgroup is shot down
>> > KillMode=process-group → only the process group of the process we forked
>> > is shot down
>> > KillMode
On Tue, 2010-06-01 at 04:13 +0200, Lennart Poettering wrote:
> On Wed, 26.05.10 22:06, Björn Persson (bj...@rombobjörn.se) wrote:
>
> > This suggests to me that environment variables isn't the right way to do
> > this.
> > Environment variables are good for parameters that should be available t
On Tue, 2010-06-01 at 04:13 +0200, Lennart Poettering wrote:
> On Wed, 26.05.10 22:06, Björn Persson (bj...@rombobjörn.se) wrote:
>
> > This suggests to me that environment variables isn't the right way to do
> > this.
> > Environment variables are good for parameters that should be available to
On Tue, 01.06.10 01:56, Mike Fedyk (mfe...@mikefedyk.com) wrote:
> > KillMode=control-group → the entire cgroup is shot down
> > KillMode=process-group → only the process group of the process we forked is
> > shot down
> > KillMode=process → only the process we forked is shot down
> > KillMode=no
On Tue, 2010-06-01 at 02:52 +0200, Lennart Poettering wrote:
> On Wed, 26.05.10 14:47, Simo Sorce (sso...@redhat.com) wrote:
>
> > > environment variables are normally inherited when forking/execing. We
> > > want to make sure that only the process we actually start ourselves
> > > parses and hand
On Mon, May 31, 2010 at 5:32 PM, Lennart Poettering
wrote:
> On Wed, 26.05.10 09:01, Jeff Spaleta (jspal...@gmail.com) wrote:
>
>>
>> On Wed, May 26, 2010 at 5:55 AM, Lennart Poettering
>> wrote:
>> > Well, that depends on configuration.
>>
>> > In systemd you can choose individually for each uni
On 6/1/2010 5:45 AM, Lennart Poettering wrote:
> Guys, nobody wants to take away configuration options. You can edit the
> .service files too, and readjust things. You can even plug in shell
> scripts here and there and wherever it suits you.
>
> There are not plans to make configuration of systemd
On 05/23/2010 05:21 AM, Lennart Poettering wrote:
> On Sun, 23.05.10 00:04, Ilyes Gouta (ilyes.go...@gmail.com) wrote:
>
> Heya,
>
>
>> So how fast is a systemd boot (with all the changes to the scripts)
>> compared to the current F13 setup? How about a ratio?
>>
> Please be patient. To quo
On Sat, 29.05.10 21:00, Roberto Ragusa (m...@robertoragusa.it) wrote:
>
> Kevin Kofler wrote:
>
> > Roberto Ragusa wrote:
> >> I need to change firewalls rules and routing rules in the middle of the
> >> init scripts, because I have a multihomed internet connection and remote
> >> filesystems an
On Sat, 29.05.10 19:48, Roberto Ragusa (m...@robertoragusa.it) wrote:
>
> Kevin Kofler wrote:
> > Jeremy Sanders wrote:
> >>
> >> You're suggesting hammering shut the insides of linux to stop people
> >> playing around and reducing freedom - sounds like you want Fedora to be
> >> like the product
On Sat, 29.05.10 19:27, Roberto Ragusa (m...@robertoragusa.it) wrote:
>
> Kevin Kofler wrote:
> > Jon Masters wrote:
> >> Didn't we "decide" that Fedora was intended for more technical users? I
> >> don't see many technical users crying out for a hammered shut init
> >> system where they feel lik
On Wed, 26.05.10 19:45, Nicolas Mailhot (nicolas.mail...@laposte.net) wrote:
>
> Le dimanche 23 mai 2010 à 00:34 +0200, Lennart Poettering a écrit :
>
> > ATM everything looks rosy. I just finished porting over all F13
> > installed-by-default daemons to socket activation, and a few more (and
>
On Wed, 26.05.10 13:37, Przemek Klosowski (przemek.klosow...@nist.gov) wrote:
>
> On 05/26/2010 12:07 PM, Adam Williamson wrote:
>
> >> It is not like you want to edit the scripts all the time, so there is
> >> no reason for them being scripts.
> >
> > I beg to differ. I've had to create or modi
On Wed, 26.05.10 22:06, Björn Persson (bj...@rombobjörn.se) wrote:
> This suggests to me that environment variables isn't the right way to do
> this.
> Environment variables are good for parameters that should be available to
> many
> processes. Command line parameters are better when the para
On Wed, 26.05.10 18:02, Scott James Remnant (sc...@canonical.com) wrote:
> On Wed, 2010-05-26 at 18:14 +0200, Lennart Poettering wrote:
>
> > Oh come on. Thanks for turning this into something personal.
> >
> You did that last week - I got forwarded logs from #systemd. That's
> probably why I w
On Wed, 26.05.10 14:47, Simo Sorce (sso...@redhat.com) wrote:
> > environment variables are normally inherited when forking/execing. We
> > want to make sure that only the process we actually start ourselves
> > parses and handles LISTEN_FDS. We want to avoid that if this daemon
> > might spawn so
On Wed, 26.05.10 12:27, Adam Williamson (awill...@redhat.com) wrote:
> > The plan is to reduce what is currenlty done in files like
> > /etc/init.d/messagebus to files like
> > http://0pointer.de/public/dbus.service.
> >
> > And those files you can edit just fine, and reconfigure.
>
> There's no
On Wed, 26.05.10 13:08, Colin Walters (walt...@verbum.org) wrote:
> >> I beg to differ. I've had to create or modify initscripts quite often,
> >> either as a sysadmin or a packager. If this is now going to require C
> >> coding skills, I'm not going to be able to do it. I don't think it's
> >> sa
On Wed, 26.05.10 12:57, Colin Walters (walt...@verbum.org) wrote:
>
> On Wed, May 26, 2010 at 12:50 PM, Lennart Poettering
> wrote:
> >
> > http://0pointer.de/public/dbus.service.
>
> Note the ExecStartPre here, like most daemons, is conceptually busted.
> There's no reason we shouldn't lay th
On Wed, 26.05.10 09:01, Jeff Spaleta (jspal...@gmail.com) wrote:
>
> On Wed, May 26, 2010 at 5:55 AM, Lennart Poettering
> wrote:
> > Well, that depends on configuration.
>
> > In systemd you can choose individually for each unit whether you want to
> > allow it to continue run processes on shu
On Wed, 26.05.10 08:19, Jeff Spaleta (jspal...@gmail.com) wrote:
>
> On Wed, May 26, 2010 at 5:55 AM, Lennart Poettering
> wrote:
> > In systemd you can choose individually for each unit whether you want to
> > allow it to continue run processes on shut down, whether you want the
> > main proces
On Wed, 26.05.10 10:16, Casey Dahlin (cdah...@redhat.com) wrote:
> > Who is "we"?
> >
>
> Upstart has about 1.7 developers. The 1 is Scott, myself and Johann Kiviniemi
> fight over the .7.
the bzr history tells a different story.
>
> > > The problem we've found is that cgroups are too aggress
On Wed, 26.05.10 12:49, Matthew Miller (mat...@mattdm.org) wrote:
>
> On Wed, May 26, 2010 at 06:39:43PM +0200, drago01 wrote:
> > Again the sysadmin case just implies that something *else* is broken.
>
> Sure. As a distribution, we don't have control over upstream projects and
> their assumptio
On Wed, 26.05.10 09:53, Andrew Parker (andrewpar...@bigfoot.com) wrote:
> >> I couldn't agree more. They need to be scripts, considering how seldom
> >> they actually run it makes even less sense to chase down optimization in
> >> them by making them compiled.
> >
> > -21 million.
> >
> > Scripts
On Sun, 30.05.10 00:38, Xose Vazquez Perez (xose.vazq...@gmail.com) wrote:
>
> On 05/22/2010 11:06 PM, Lennart Poettering wrote:
>
> > On Sat, 22.05.10 18:30, Xose Vazquez Perez (xose.vazq...@gmail.com) wrote:
> >
> >>
> >> Is it worth using tmpfs for some directories(/var/run, lock...) ?
> >
>
On Wed, 26.05.10 09:08, Seth Vidal (skvi...@fedoraproject.org) wrote:
> > Scripts are a crutch to avoid properly designed daemons and
> > configuration systems. I never edit initscripts to "configure"
> > daemons, because they would just be overwritten at the next package
> > upgrade. Configurat
On Wed, 26.05.10 19:54, Nicolas Mailhot (nicolas.mail...@laposte.net) wrote:
>
> Le mercredi 26 mai 2010 à 19:39 +0200, Alexander Boström a écrit :
> > ons 2010-05-26 klockan 10:01 +0100 skrev James Findley:
> >
> > > It's really not at all uncommon for me to need to modify an init script.
> >
On Wed, 26.05.10 19:39, Alexander Boström (a...@root.snowtree.se) wrote:
>
> ons 2010-05-26 klockan 10:01 +0100 skrev James Findley:
>
> > It's really not at all uncommon for me to need to modify an init script.
> > There would be much rage if in order to do this I had to download the
> > SR
On Thu, 27.05.10 10:13, Chris Adams (cmad...@hiwaay.net) wrote:
>
> Once upon a time, Kevin Kofler said:
> > Editing the code is the wrong way to make "simple local changes".
>
> That is only true if you can anticipate every task every system admin
> will ever need to do with your tools.
>
> I
On Wed, 26.05.10 14:57, Emmanuel Seyman (emmanuel.sey...@club-internet.fr)
wrote:
>
> * Ola Thoresen [26/05/2010 14:39] :
> >
> > Would it not be more fruitful to discuss _why_ you (we?) need to edit
> > the initscripts? Describe what functionality is missing or wrong in the
> > default ones?
On Thu, 27.05.10 07:15, Matthew Miller (mat...@mattdm.org) wrote:
>
> On Thu, May 27, 2010 at 10:10:35AM +0200, Harald Hoyer wrote:
> > We mainly speek about rc.sysinit, which most of you don't touch, because it
> > would be overwritten the next initscripts update anyway.
>
> I would never touc
On Wed, 26.05.10 14:08, Jon Masters (jonat...@jonmasters.org) wrote:
> > I couldn't agree more. They need to be scripts, considering how seldom
> > they actually run it makes even less sense to chase down optimization in
> > them by making them compiled.
>
> I *very* strongly agree also. I do c
On Wed, 26.05.10 17:41, Bill Nottingham (nott...@redhat.com) wrote:
>
> James Findley (s...@gmx.com) said:
> > Actually the blog post is proposing exactly that, as I read it. And it
> > seems not only that lots of other people read it the same way, but some
> > even agree with it.
> >
> > So
On Wed, 26.05.10 15:42, James Findley (s...@gmx.com) wrote:
> > It is completely clear that there needs to be some flexibility in any
> > init system to cater to real-world services.
> >
> > But it is also clear that there is a difference between gobs of shell
> > script and nice and clean files l
On 05/22/2010 11:06 PM, Lennart Poettering wrote:
> On Sat, 22.05.10 18:30, Xose Vazquez Perez (xose.vazq...@gmail.com) wrote:
>
>>
>> Is it worth using tmpfs for some directories(/var/run, lock...) ?
>
> Yes. But this requires some changes all across the distro, just have a
> look at the output o
Kevin Kofler wrote:
> Roberto Ragusa wrote:
>> I need to change firewalls rules and routing rules in the middle of the
>> init scripts, because I have a multihomed internet connection and remote
>> filesystems and I need the firewall closed and then opened in a way which
>> is dependent on the IP
Roberto Ragusa wrote:
> - having control of the mixer
The KMix ALSA backend is not going away.
https://fedoraproject.org/wiki/Features/KDE_PulseAudio_Integration#Release_Notes
> I need to change firewalls rules and routing rules in the middle of the
> init scripts, because I have a multihomed int
Kevin Kofler wrote:
> Jeremy Sanders wrote:
>>
>> You're suggesting hammering shut the insides of linux to stop people
>> playing around and reducing freedom - sounds like you want Fedora to be
>> like the products of other large propitiatory systems.
>
> C code can be changed too, if really neede
On Sat, May 29, 2010 at 07:27:57PM +0200, Roberto Ragusa wrote:
> Kevin Kofler wrote:
> > Jon Masters wrote:
> >> Didn't we "decide" that Fedora was intended for more technical users? I
> >> don't see many technical users crying out for a hammered shut init
> >> system where they feel like they hav
Kevin Kofler wrote:
> Jon Masters wrote:
>> Didn't we "decide" that Fedora was intended for more technical users? I
>> don't see many technical users crying out for a hammered shut init
>> system where they feel like they have to go to their auto mechanic to
>> attach the right magic dongle to fix
Jon Masters wrote:
> Didn't we "decide" that Fedora was intended for more technical users? I
> don't see many technical users crying out for a hammered shut init
> system where they feel like they have to go to their auto mechanic to
> attach the right magic dongle to fix it when it breaks.
A real
On Fri, May 28, 2010 at 2:06 PM, Jon Masters wrote:
> Didn't we "decide" that Fedora was intended for more technical users? I
> don't see many technical users crying out for a hammered shut init
> system where they feel like they have to go to their auto mechanic to
> attach the right magic dongl
On Thu, 2010-05-27 at 15:39 +0200, Kevin Kofler wrote:
> Jeremy Sanders wrote:
> > You're suggesting hammering shut the insides of linux to stop people
> > playing around and reducing freedom - sounds like you want Fedora to be
> > like the products of other large propitiatory systems.
>
> C code
On Thu, May 27, 2010 at 10:13:16AM -0500, Chris Adams wrote:
> Once upon a time, Kevin Kofler said:
> > Editing the code is the wrong way to make "simple local changes".
>
> That is only true if you can anticipate every task every system admin
> will ever need to do with your tools.
>
> I've edi
Once upon a time, Kevin Kofler said:
> Editing the code is the wrong way to make "simple local changes".
That is only true if you can anticipate every task every system admin
will ever need to do with your tools.
I've edited init scripts for multiple reasons. For example, I have
multiple instan
On Thu, May 27, 2010 at 9:56 AM, Jeremy Sanders
wrote:
> drago01 wrote:
> [..]
> You're suggesting hammering shut the insides of linux to stop people playing
> around and reducing freedom - sounds like you want Fedora to be like the
> products of other large propitiatory systems.
What?
You can e
Jeremy Sanders wrote:
> What rubbish. For instance, we customised an early Fedora to work on a
> diskless NFS rooted system, mainly by mucking around with init scripts.
> Being able to easily edit these files made this project work and work
> quickly. Trying to get upstream to special case our part
On Thu, May 27, 2010 at 03:14:54PM +0200, Kevin Kofler wrote:
> > That's not down to it being a shell script though; it's because it's a
> > crufty mess.
> … which is exactly why it should be handled inside the init system instead
> of being that mess of a shell script. :-)
Maybe. That cruft is a
Matthew Miller wrote:
> That's not down to it being a shell script though; it's because it's a
> crufty mess.
… which is exactly why it should be handled inside the init system instead
of being that mess of a shell script. :-)
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproje
Chris Adams wrote:
> No, it isn't. It makes the process much more opaque to system
> administrators and makes it harder to make quick fixes and simple local
> changes.
Editing the code is the wrong way to make "simple local changes".
> If there isn't a measurable and significant speed improvemen
On Thu, May 27, 2010 at 10:10:35AM +0200, Harald Hoyer wrote:
> We mainly speek about rc.sysinit, which most of you don't touch, because it
> would be overwritten the next initscripts update anyway.
I would never touch it with a permanent change, but I definitely make
debugging changes to it ofte
On 05/26/2010 06:07 PM, Adam Williamson wrote:
> On Wed, 2010-05-26 at 12:42 +0200, drago01 wrote:
>> On Wed, May 26, 2010 at 5:02 AM, Casey Dahlin wrote:
>>> On Tue, May 25, 2010 at 05:45:07PM +0200, Lennart Poettering wrote:
On Tue, 25.05.10 10:21, Casey Dahlin (cdah...@redhat.com) wrote:
>
On 05/26/2010 02:54 PM, Seth Vidal wrote:
>
>
> On Wed, 26 May 2010, Simo Sorce wrote:
>
>> While you don't edit them *all* the time, it is something that is done
>> regularly, and it is something most admins can do with ease.
>> Turn them in a C program and you left admins out in the cold, most of
On 05/26/2010 10:20 PM, Nathanael D. Noblet wrote:
> On 05/26/2010 06:57 AM, Emmanuel Seyman wrote:
>> * Ola Thoresen [26/05/2010 14:39] :
>>>
>>> Would it not be more fruitful to discuss _why_ you (we?) need to edit
>>> the initscripts? Describe what functionality is missing or wrong in the
>>> d
drago01 wrote:
>> I beg to differ. I've had to create or modify initscripts quite often,
>> either as a sysadmin or a packager.
>
> Again the sysadmin case just implies that something *else* is broken.
> Well if changing over to C does only get rid of this "disease" it
> would be enough of a gai
Bill Nottingham wrote:
> Jeremy Sanders (jer...@jeremysanders.net) said:
>> Something like Lua would be very good. The overheads over C would be
>> minimal, and it would have the advantage of being editable.
>>
>> I've had to edit an init script to get something working properly many
>> times.
>
drago01 wrote:
> Well spawing your logic further means we should avoid compiled
> programs at all, what if I want configure $app by editing its source
> code?
> Oh wait it is written in C ...
>
> If it goes down to "want to edit scripts for configuration reasons"
> (which isn't sane anyway) compa
Once upon a time, Kevin Kofler said:
> IMHO replacing slow interpreted code by fast compiled code is always a good
> idea, especially so if the interpreted code is shell code with its massive
> abuse of process spawning.
No, it isn't. It makes the process much more opaque to system
administrat
On Wed, May 26, 2010 at 23:39:49 +0200,
Kevin Kofler wrote:
> seth vidal wrote:
> > It appears this subject has been picked up on lwn - so I'm certain there
> > will be a fruitful, productive and constructive discussion there.
>
> Hahaha! You gotta be kidding! LWN keeps posting flamewars as "ne
On Wed, 2010-05-26 at 23:39 +0200, Kevin Kofler wrote:
> seth vidal wrote:
> > It appears this subject has been picked up on lwn - so I'm certain there
> > will be a fruitful, productive and constructive discussion there.
>
> Hahaha! You gotta be kidding! LWN keeps posting flamewars as "news" and
On Wed, 2010-05-26 at 23:39 +0200, Kevin Kofler wrote:
> seth vidal wrote:
> > It appears this subject has been picked up on lwn - so I'm certain there
> > will be a fruitful, productive and constructive discussion there.
>
> Hahaha! You gotta be kidding! LWN keeps posting flamewars as "news" and
James Findley (s...@gmx.com) said:
> Actually the blog post is proposing exactly that, as I read it. And it
> seems not only that lots of other people read it the same way, but some
> even agree with it.
>
> So I'm not sure I see how this is going off into the weeds - if
> transitioning some/
seth vidal wrote:
> It appears this subject has been picked up on lwn - so I'm certain there
> will be a fruitful, productive and constructive discussion there.
Hahaha! You gotta be kidding! LWN keeps posting flamewars as "news" and
their comments are infested by trolls like no other place!
Jeremy Sanders (jer...@jeremysanders.net) said:
> Something like Lua would be very good. The overheads over C would be
> minimal, and it would have the advantage of being editable.
>
> I've had to edit an init script to get something working properly many
> times.
If you're going to want them
James Findley wrote:
> You're comparing the wrong thing here - I was demonstrating that it
> doesn't take noticeably longer to spawn awk than a small C app on modern
> systems.
> thus using:
> for i in {1..1000}; do awk 'BEGIN{print "Hello World"}' > /dev/null; done
> for i in {1..1000}; do ./hello
On 05/26/2010 06:57 AM, Emmanuel Seyman wrote:
> * Ola Thoresen [26/05/2010 14:39] :
>>
>> Would it not be more fruitful to discuss _why_ you (we?) need to edit
>> the initscripts? Describe what functionality is missing or wrong in the
>> default ones?
>
> Editing environnement variables and indic
Lennart Poettering wrote:
> Regarding the LISTEN_PID env var:
>
> environment variables are normally inherited when forking/execing. We
> want to make sure that only the process we actually start ourselves
> parses and handles LISTEN_FDS. We want to avoid that if this daemon
> might spawn some oth
On Wed, 2010-05-26 at 11:32 -0500, Michael Cronenworth wrote:
> OTOH, why is this even a sub-topic in this sub-topic of a thread? I'd
> love to see some numbers from the complainers about scripting being
> slow. I have a normal Fedora 13 x86_64 system that boots through
> initscripts in under 1
On Wed, 2010-05-26 at 18:50 +0200, Lennart Poettering wrote:
> > I beg to differ. I've had to create or modify initscripts quite often,
> > either as a sysadmin or a packager. If this is now going to require C
> > coding skills, I'm not going to be able to do it. I don't think it's
> > safe to ass
On Wed, 26 May 2010 18:20:08 +0200
Lennart Poettering wrote:
> Regarding the LISTEN_PID env var:
>
> environment variables are normally inherited when forking/execing. We
> want to make sure that only the process we actually start ourselves
> parses and handles LISTEN_FDS. We want to avoid that
On Wed, 2010-05-26 at 14:08 -0400, Jon Masters wrote:
> On Wed, 2010-05-26 at 08:54 -0400, Seth Vidal wrote:
> >
> > On Wed, 26 May 2010, Simo Sorce wrote:
> >
> > > While you don't edit them *all* the time, it is something that is done
> > > regularly, and it is something most admins can do with
On Wed, 2010-05-26 at 08:54 -0400, Seth Vidal wrote:
>
> On Wed, 26 May 2010, Simo Sorce wrote:
>
> > While you don't edit them *all* the time, it is something that is done
> > regularly, and it is something most admins can do with ease.
> > Turn them in a C program and you left admins out in the
Le mercredi 26 mai 2010 à 19:39 +0200, Alexander Boström a écrit :
> ons 2010-05-26 klockan 10:01 +0100 skrev James Findley:
>
> > It's really not at all uncommon for me to need to modify an init script.
> > There would be much rage if in order to do this I had to download the
> > SRPM, extra
Le dimanche 23 mai 2010 à 00:34 +0200, Lennart Poettering a écrit :
> ATM everything looks rosy. I just finished porting over all F13
> installed-by-default daemons to socket activation, and a few more (and
> the patches are good enough to be upstreamable).
For this kind of stuff I strongly sugg
ons 2010-05-26 klockan 10:01 +0100 skrev James Findley:
> It's really not at all uncommon for me to need to modify an init script.
> There would be much rage if in order to do this I had to download the
> SRPM, extract the init code, figure out what I needed to change, modify
> it, recompile
On 05/26/2010 12:07 PM, Adam Williamson wrote:
>> It is not like you want to edit the scripts all the time, so there is
>> no reason for them being scripts.
>
> I beg to differ. I've had to create or modify initscripts quite often,
> either as a sysadmin or a packager. If this is now going to requ
On Wed, May 26, 2010 at 12:50 PM, Lennart Poettering
wrote:
> On Wed, 26.05.10 09:07, Adam Williamson (awill...@redhat.com) wrote:
>
>>
>> On Wed, 2010-05-26 at 12:42 +0200, drago01 wrote:
>> > On Wed, May 26, 2010 at 5:02 AM, Casey Dahlin wrote:
>> > > On Tue, May 25, 2010 at 05:45:07PM +0200, L
On Wed, 2010-05-26 at 18:14 +0200, Lennart Poettering wrote:
> Oh come on. Thanks for turning this into something personal.
>
You did that last week - I got forwarded logs from #systemd. That's
probably why I wasn't in a great mood with you this morning ;-)
> I'd prefer it we would keep this di
On Wed, May 26, 2010 at 5:55 AM, Lennart Poettering
wrote:
> Well, that depends on configuration.
> In systemd you can choose individually for each unit whether you want to
> allow it to continue run processes on shut down, whether you want the
> main process killed, the process group to be kille
On Wed, May 26, 2010 at 12:50 PM, Lennart Poettering
wrote:
>
> http://0pointer.de/public/dbus.service.
Note the ExecStartPre here, like most daemons, is conceptually busted.
There's no reason we shouldn't lay that file down once when the OS is
installed, and not check it every boot. Or alterna
On Wed, 26.05.10 09:07, Adam Williamson (awill...@redhat.com) wrote:
>
> On Wed, 2010-05-26 at 12:42 +0200, drago01 wrote:
> > On Wed, May 26, 2010 at 5:02 AM, Casey Dahlin wrote:
> > > On Tue, May 25, 2010 at 05:45:07PM +0200, Lennart Poettering wrote:
> > >> On Tue, 25.05.10 10:21, Casey Dahli
On Wed, May 26, 2010 at 06:39:43PM +0200, drago01 wrote:
> Again the sysadmin case just implies that something *else* is broken.
Sure. As a distribution, we don't have control over upstream projects and
their assumptions for daemon startup, shutdown, status, etc. Sometimes, they
want odd things.
1 - 100 of 180 matches
Mail list logo
