The system project seems to have made great strides to the point that now there
are definite philosophical differences. The people on both sides have their
own opinions of what the direction should be given how much progress has
occurred.
I think this would a very good time for a fork of the p
On Wed, 2014-10-22 at 02:13 +0200, Martin Steigerwald wrote:
> With that I perceive starts an answer on a technical matter ends with what I
> received as a dire personal attack: I.e. calling me names.
I think it was a mostly justified criticism of your posting style here.
> I will make an effort
On Wed, Oct 22, 2014 at 02:42:13AM +0200, Ronny Chevalier wrote:
> 2014-10-22 2:13 GMT+02:00 Ronny Chevalier :
> > 2014-10-22 1:48 GMT+02:00 Zbigniew Jędrzejewski-Szmek :
> >> On Sat, Oct 18, 2014 at 06:30:02PM +0200, Ronny Chevalier wrote:
> >>> It helps editing units by either creating a drop-in
2014-10-22 2:13 GMT+02:00 Ronny Chevalier :
> 2014-10-22 1:48 GMT+02:00 Zbigniew Jędrzejewski-Szmek :
>> On Sat, Oct 18, 2014 at 06:30:02PM +0200, Ronny Chevalier wrote:
>>> It helps editing units by either creating a drop-in file, like
>>> /etc/systemd/system/my.service.d/amendments.conf, or by co
2014-10-22 1:48 GMT+02:00 Zbigniew Jędrzejewski-Szmek :
> On Sat, Oct 18, 2014 at 06:30:02PM +0200, Ronny Chevalier wrote:
>> It helps editing units by either creating a drop-in file, like
>> /etc/systemd/system/my.service.d/amendments.conf, or by copying the
>> original unit from /usr/lib/systemd/
Colin,
I had the feeling that is a bad idea to read your mail before I go to sleep.
But I was interested in what you have to say since you made quite an effort in
your reply to me. And now I can´t sleep since my head if full of thoughts and
I am full of emotions as well.
With that I perceive s
On Sat, Oct 18, 2014 at 06:30:02PM +0200, Ronny Chevalier wrote:
> It helps editing units by either creating a drop-in file, like
> /etc/systemd/system/my.service.d/amendments.conf, or by copying the
> original unit from /usr/lib/systemd/ to /etc/systemd/ if the --full
> option is specified. Then i
On Wed, Oct 22, 2014 at 12:29:15AM +0200, Ronny Chevalier wrote:
> 2014-10-21 0:51 GMT+02:00 Lennart Poettering :
> > On Sat, 18.10.14 18:30, Ronny Chevalier (chevalier.ro...@gmail.com) wrote:
> >
> > Looks pretty good. A few comments.
> >
> >> +
> >> +static int unit_file_copy_if_needed(const char
2014-10-21 0:51 GMT+02:00 Lennart Poettering :
> On Sat, 18.10.14 18:30, Ronny Chevalier (chevalier.ro...@gmail.com) wrote:
>
> Looks pretty good. A few comments.
>
>> +
>> +static int unit_file_copy_if_needed(const char *unit_name, const char
>> *fragment_path, char **new_path) {
>> +char
This test temporarily creates several thousand unit files and checks
the performance of unit_file_get_list.
This test is currently added to manual_tests only since it does not
pass.
This test does pass if the subsequent enabled unit cache patch is
applied.
---
.gitignore| 1 +
The current find_symlinks_fd code traverses the config directories
duplicatively. This is a performance problem if 1000s of units are
being controlled. This patch adds a hashmap cache of symbolic link
state which is filled in one traversal and then consulted as needed to
prevent re-traversal.
The
This test constructs different unit file states and checks the output
of unit_file_get_state and unit_file_get_list for each.
This test characterizes the current output of the master branch in
preparation for a patch which improves the performance of unit state
detection in the face of thousands o
Martin Steigerwald wrote on 21/10/14 10:25:
> Am Mittwoch, 8. Oktober 2014, 10:54:00 schrieb Lennart Poettering:
>> On Tue, 07.10.14 23:40, Uoti Urpala (uoti.urp...@pp1.inet.fi) wrote:
>>> On Tue, 2014-10-07 at 14:15 -0400, Rob Owens wrote:
My question really isn't "why are the Debian dependen
2014-10-21 11:09 GMT+02:00 Lennart Poettering :
> On Sat, 18.10.14 18:30, Ronny Chevalier (chevalier.ro...@gmail.com) wrote:
>
> Three more suggestions after thinking about this a bit more...
>
>> +static int unit_file_drop_in(const char *unit_name, const char
>> *config_home, char **new_path) {
>
On Tuesday 21 October 2014 at 21:57:09, Michal Sekletar wrote:
> On Tue, Oct 21, 2014 at 09:39:46PM +0400, Ivan Shapovalov wrote:
> > On Tuesday 21 October 2014 at 19:03:17, Michal Sekletar wrote:
> > > On Tue, Oct 14, 2014 at 09:04:56AM +0200, Jan Synacek wrote:
> > > > Michal Sekletar wr
2014-10-21 11:01 GMT+02:00 Lennart Poettering :
> On Tue, 21.10.14 03:01, Ronny Chevalier (chevalier.ro...@gmail.com) wrote:
>
>> >> +static int get_editors(char ***editors) {
>> >> +char **tmp_editors = strv_new("nano", "vim", "vi", NULL);
>> >
>> > Please avoid calling functions and decla
On Tue, 21.10.14 13:16, Daniel Mack (zon...@kemper.freedesktop.org) wrote:
> src/libsystemd/sd-bus/bus-kernel.c | 16 +---
> src/libsystemd/sd-bus/kdbus.h |3 ++-
> 2 files changed, 15 insertions(+), 4 deletions(-)
>
> New commits:
> commit 03785ad0e51b061efb9f9b3f2e328685
On Tue, Oct 21, 2014 at 09:39:46PM +0400, Ivan Shapovalov wrote:
> On Tuesday 21 October 2014 at 19:03:17, Michal Sekletar wrote:
> > On Tue, Oct 14, 2014 at 09:04:56AM +0200, Jan Synacek wrote:
> > > Michal Sekletar writes:
> > > > On Mon, Oct 13, 2014 at 09:36:16AM +0200, Jan Synacek wro
On Fri, 12.09.14 13:04, lux-integ (lux-in...@btconnect.com) wrote:
> On Friday 12 September 2014 11:53:23 Simon McVittie wrote:
> > The way to do this is to write a script in the programming language of
> > your choice (bash is one possibility), and have the systemd service file
> > run that. Ther
On Tue, 21.10.14 21:22, Christian Seiler (christ...@iwakd.de) wrote:
> Am 21.10.2014 20:09, schrieb Lennart Poettering:
> >> Debian's systemd package currently includes a variant of Martin's
> >> patch that does include additional directories. So your point that
> >> ProtectSystem= does the same
Am 21.10.2014 20:09, schrieb Lennart Poettering:
>> Debian's systemd package currently includes a variant of Martin's
>> patch that does include additional directories. So your point that
>> ProtectSystem= does the same thing on every distro is already not
>> true.
>
> Which ones precisely?
Her
On Fri, 19.09.14 17:14, Michal Sekletar (msekl...@redhat.com) wrote:
Heya,
> In cases when there is a cgroup tree in a controller hierarchy which was
> not created by us, but it looks like it was (i.e. cgroup path is the
> same as the one in systemd's named hierarchy) we shouldn't delete
> it.
S
On 21/10/14 19:18, Lennart Poettering wrote:
> Well, on some distros lib64 is a symlink on others it isn't. Doesn't
> Debian have /lib/ or so with /lib64 just a symlink to the right
> subdir?
My Debian laptop has /lib64 as a real directory, containing a
ld-linux-x86-64.so.2 symlink into /lib/.
I
Lennart Poettering [2014-10-21 20:18 +0200]:
> Well, on some distros lib64 is a symlink on others it isn't. Doesn't
> Debian have /lib/ or so with /lib64 just a symlink to the right
> subdir?
More or less:
/lib64/ld-linux-x86-64.so.2 -> /lib/x86_64-linux-gnu/ld-2.19.so
Martin
--
Martin Pitt
On Tue, 21.10.14 13:38, Simon McVittie (simon.mcvit...@collabora.co.uk) wrote:
> On 21/10/14 13:03, Christian Seiler wrote:
> > That is definitely a good point. Also note that /lib32 is not included
> > in the patch...
>
> lib64 is part of the Linux/x86_64 platform ABI (the exact path
> /lib64/ld
On Tue, 21.10.14 15:57, Christian Seiler (christ...@iwakd.de) wrote:
> Am 2014-10-21 14:28, schrieb Lennart Poettering:
> >We explicitly make no
> >assumptions on /opt because nobody knows right now what it is supposed
> >to be...
>
> Sure, I wasn't disputing that point.
>
> >Same for /usr, /bin
On Tue, 21.10.14 17:50, Michal Schmidt (mschm...@redhat.com) wrote:
> >> +static struct HashmapBase *__hashmap_new(const struct hash_ops *hash_ops,
> >> uint8_t type HASHMAP_DEBUG_PARAMS) {
> >> +HashmapBase *h;
> >> +
> >> +h = malloc0(all_hashmap_sizes[type]);
> >> +if
On Tue, 21.10.14 17:36, Michal Schmidt (mschm...@redhat.com) wrote:
> On 10/20/2014 08:23 PM, Lennart Poettering wrote:
> > On Thu, 16.10.14 09:50, Michal Schmidt (mschm...@redhat.com) wrote:
> >> Key changes that affect other code:
> >> - Sets and Hashmaps do not remember the insertion order any
On Tue, 21.10.14 14:48, Martyn Russell (mar...@lanedo.com) wrote:
> >Hmm. I would always have assumed that tracker is strictly IO-bound,
> >not CPU-bound, hence 100% sounds suspicious to me. What precisely is
> >tracker doing there that it needs to crunch that much data? Just
> >extracting some me
On Tuesday 21 October 2014 at 19:03:17, Michal Sekletar wrote:
> On Tue, Oct 14, 2014 at 09:04:56AM +0200, Jan Synacek wrote:
> > Michal Sekletar writes:
> > > On Mon, Oct 13, 2014 at 09:36:16AM +0200, Jan Synacek wrote:
> > >> Hello,
> > >>
> > >> currently, unicode characters are not correctl
On Tue, 21.10.14 18:32, Michal Sekletar (msekl...@redhat.com) wrote:
> Function queries system hostname and applies changes only when necessary.
> Also,
> migrate all client of sethostname to sethostname_idempotent while at
> it.
Looks pretty good!
> +int sethostname_idempotent(const char *s) {
On Tue, Oct 14, 2014 at 09:04:56AM +0200, Jan Synacek wrote:
> Michal Sekletar writes:
> > On Mon, Oct 13, 2014 at 09:36:16AM +0200, Jan Synacek wrote:
> >> Hello,
> >>
> >> currently, unicode characters are not correctly displayed in the
> >> console. After login, when I run /usr/bin/unicode_sta
Function queries system hostname and applies changes only when necessary. Also,
migrate all client of sethostname to sethostname_idempotent while at it.
---
src/core/hostname-setup.c | 2 +-
src/hostname/hostnamed.c | 2 +-
src/nspawn/nspawn.c | 2 +-
src/shared/util.c | 20 +
On 10/20/2014 08:42 PM, Lennart Poettering wrote:
> On Thu, 16.10.14 09:50, Michal Schmidt (mschm...@redhat.com) wrote:
>> +enum {
>> +HASHMAP_TYPE_PLAIN,
>> +HASHMAP_TYPE_LINKED,
>> +HASHMAP_TYPE_SET,
>> +__HASHMAP_TYPE_COUNT
>> +};
>
> Why is this enum anonymous?
On 10/20/2014 08:23 PM, Lennart Poettering wrote:
> On Thu, 16.10.14 09:50, Michal Schmidt (mschm...@redhat.com) wrote:
>> Key changes that affect other code:
>> - Sets and Hashmaps do not remember the insertion order anymore.
>>They can still be iterated with *_FOREACH* or *_first*, but
>>
Hi
On Mon, Oct 20, 2014 at 10:06 PM, Boris Egorov wrote:
> Oh, you are right. This should probably be left as is.
>
It should be reported to cppcheck
http://sourceforge.net/p/cppcheck/wiki/Home/
Preferably with a small test case. Ignoring false positives makes it
harder to figure out when th
Am 2014-10-21 14:28, schrieb Lennart Poettering:
We explicitly make no
assumptions on /opt because nobody knows right now what it is
supposed
to be...
Sure, I wasn't disputing that point.
Same for /usr, /bin, /sbin, and the other stuff Martin#s
patch added: we cannot make assumptions about
On 21/10/14 12:21, Lennart Poettering wrote:
On Tue, 21.10.14 12:03, Martyn Russell (mar...@lanedo.com) wrote:
What precisely are you setting with sched_setscheulder() and ioprio_set()?
https://git.gnome.org/browse/tracker/tree/src/libtracker-common/tracker-sched.c#n29
and
https://git.gnome
Am 21.10.2014 um 14:38 schrieb Simon McVittie:
On 21/10/14 13:03, Christian Seiler wrote:
That is definitely a good point. Also note that /lib32 is not included
in the patch...
lib64 is part of the Linux/x86_64 platform ABI (the exact path
/lib64/ld-linux-x86-64.so.2 is hard-coded into every
On 21/10/14 13:03, Christian Seiler wrote:
> That is definitely a good point. Also note that /lib32 is not included
> in the patch...
lib64 is part of the Linux/x86_64 platform ABI (the exact path
/lib64/ld-linux-x86-64.so.2 is hard-coded into every Linux/x86_64
executable) so it cannot be conside
On Tue, 21.10.14 14:03, Christian Seiler (christ...@iwakd.de) wrote:
> Am 2014-10-20 17:05, schrieb Lennart Poettering:
> >I am sorry, but this is nothing we want to support. Monopolizing the
> >OS in /usr is what makes ProtectSystem= work. If you split things up
> >into many dirs then you will si
Am 2014-10-20 17:05, schrieb Lennart Poettering:
I am sorry, but this is nothing we want to support. Monopolizing the
OS in /usr is what makes ProtectSystem= work. If you split things up
into many dirs then you will simply not get the same level of
protection. We will not try to list every possib
On Tue, 21.10.14 12:03, Martyn Russell (mar...@lanedo.com) wrote:
> >What precisely are you setting with sched_setscheulder() and ioprio_set()?
>
> https://git.gnome.org/browse/tracker/tree/src/libtracker-common/tracker-sched.c#n29
>
> and
>
> https://git.gnome.org/browse/tracker/tree/src/libtr
On 21/10/14 11:06, Lennart Poettering wrote:
What functionality of cgroups were you precisely using?
This was not set up by the Tracker team but another Team at Nokia. Also,
perhaps Philip or Ivan have some comments and remember better.
It's a while back now, but from what I remember on the
On 21/10/14 09:37, Martin Steigerwald wrote:
> In my long years of using Debian and also doing some packages for it in the
> last years I never saw that any introduced changed caused a serious "we may
> need to fork" like announcement
I've seen several instances of Debian people *actually* forki
On Tue, 21.10.14 09:53, Martyn Russell (mar...@lanedo.com) wrote:
> On 20/10/14 21:12, Lennart Poettering wrote:
> >On Tue, 14.10.14 15:35, Martyn Russell (mar...@lanedo.com) wrote:
>
> Hej Lennart,
>
> >I am not entirely sure what cgroups would really give you that
> >sched_setscheduler(), iopr
Am Dienstag, 21. Oktober 2014, 11:59:09 schrieb Lennart Poettering:
> On Tue, 21.10.14 11:47, Martin Steigerwald (mar...@lichtvoll.de) wrote:
> > > > So or so… I think its this kind of attitude that triggers most of the
> > > > polarity and split.
> > >
> > > Well, our priority is to solve technic
Am Dienstag, 21. Oktober 2014, 11:52:50 schrieb Lennart Poettering:
> > When Microsoft back then did something like this it was called "Embrace,
> > Extend and Extinguish"¹…
>
> Oh come on. You are just being a dick now.
For now just this:
Thats a personal accusation.
I didn´t attack you pers
On Tue, 21.10.14 11:47, Martin Steigerwald (mar...@lichtvoll.de) wrote:
> > > So or so… I think its this kind of attitude that triggers most of the
> > > polarity and split.
> >
> > Well, our priority is to solve technical problems in a way we perceive
> > elegant and minimal. Your priority appea
Am Dienstag, 21. Oktober 2014, 11:21:36 schrieb Lennart Poettering:
> On Tue, 21.10.14 10:53, Martin Steigerwald (mar...@lichtvoll.de) wrote:
> > So, aside from it being additional work, is there any *solid* or even
> > *unavoidable* technical reason to couple functionality that tightly?
>
> Yes,
On Tue, Oct 21, 2014 at 11:35 AM, Martin Steigerwald
wrote:
> Am Dienstag, 21. Oktober 2014, 11:07:01 schrieben Sie:
>> On Tue, Oct 21, 2014 at 10:53 AM, Martin Steigerwald
>>
>> wrote:
>> > Am Montag, 6. Oktober 2014, 21:53:04 schrieb Zbigniew Jędrzejewski-Szmek:
>> >> > Systemd-shim provides so
Am Dienstag, 21. Oktober 2014, 11:26:16 schrieben Sie:
> On Tue, Oct 21, 2014 at 11:08 AM, Martin Steigerwald
>
> wrote:
> > Then systemd may use it as PID 1, but if someother wants to use it in own
> > project, can use it as well. I consider cgroups as part of the kernel API
> > and I highly dis
On Tue, 21.10.14 11:08, Martin Steigerwald (mar...@lichtvoll.de) wrote:
> > systemd as init", but "logind has to depend on the system having cgroup
> > support, and there's no equally good cgroup support available for inits
> > other than systemd". It is possible to provide the relevant cgroup
> >
Am Dienstag, 21. Oktober 2014, 11:07:01 schrieben Sie:
> On Tue, Oct 21, 2014 at 10:53 AM, Martin Steigerwald
>
> wrote:
> > Am Montag, 6. Oktober 2014, 21:53:04 schrieb Zbigniew Jędrzejewski-Szmek:
> >> > Systemd-shim provides some functionality that systemd-sysv provides,
> >> >
> >> > and al
On Tue, Oct 21, 2014 at 11:08 AM, Martin Steigerwald
wrote:
> Then systemd may use it as PID 1, but if someother wants to use it in own
> project, can use it as well. I consider cgroups as part of the kernel API and
> I highly dislike the battle on which of the available solutions will get
> contr
Am Mittwoch, 8. Oktober 2014, 10:54:00 schrieb Lennart Poettering:
> On Tue, 07.10.14 23:40, Uoti Urpala (uoti.urp...@pp1.inet.fi) wrote:
> > On Tue, 2014-10-07 at 14:15 -0400, Rob Owens wrote:
> > > My question really isn't "why are the Debian dependencies the way they
> > > are". I understand th
On Tue, 21.10.14 10:53, Martin Steigerwald (mar...@lichtvoll.de) wrote:
> So, aside from it being additional work, is there any *solid* or even
> *unavoidable* technical reason to couple functionality that tightly?
Yes, there always is. For logind for example we need to be able to
group the proc
On Sat, 18.10.14 18:30, Ronny Chevalier (chevalier.ro...@gmail.com) wrote:
Three more suggestions after thinking about this a bit more...
> +static int unit_file_drop_in(const char *unit_name, const char *config_home,
> char **new_path) {
> +char *tmp_path;
> +int r;
> +
> +
Am Dienstag, 7. Oktober 2014, 23:40:45 schrieb Uoti Urpala:
> On Tue, 2014-10-07 at 14:15 -0400, Rob Owens wrote:
> > My question really isn't "why are the Debian dependencies the way they
> > are". I understand that. I was trying to highlight the strange
> > situation of a desktop application re
On Tue, Oct 21, 2014 at 10:53 AM, Martin Steigerwald
wrote:
> Am Montag, 6. Oktober 2014, 21:53:04 schrieb Zbigniew Jędrzejewski-Szmek:
>> > Systemd-shim provides some functionality that systemd-sysv provides,
>> > and allows admins to use init systems other than systemd while still
>> > install
On Tue, 21.10.14 03:01, Ronny Chevalier (chevalier.ro...@gmail.com) wrote:
> >> +static int get_editors(char ***editors) {
> >> +char **tmp_editors = strv_new("nano", "vim", "vi", NULL);
> >
> > Please avoid calling functions and declaring variables in one line.
> >
> > Also, there's an OO
On 20/10/14 21:12, Lennart Poettering wrote:
On Tue, 14.10.14 15:35, Martyn Russell (mar...@lanedo.com) wrote:
Hej Lennart,
I am not entirely sure what cgroups would really give you that
sched_setscheduler(), ioprio_set(), setrlimit() wouldn't give you
It's another approach, more of a sandb
Am Montag, 6. Oktober 2014, 21:53:04 schrieb Zbigniew Jędrzejewski-Szmek:
> > Systemd-shim provides some functionality that systemd-sysv provides,
> > and allows admins to use init systems other than systemd while still
> > installing things like brasero. I think this is a great thing,
> > exce
Hi Rob,
Am Montag, 6. Oktober 2014, 14:56:22 schrieb Rob Owens:
> - Original Message -
>
> > From: "Martin Steigerwald"
> >
> > Heck, I started a thread here and then didn´t manage to take time to
> > carefully
> > read it and reply here and there as I see fit. But I challenged people o
Am Sonntag, 21. September 2014, 15:31:15 schrieb Martin Steigerwald:
> Hello!
>
> I know this is a daring post.
>
> I just have one question. In the light of
>
> http://boycottsystemd.org/
>
> http://uselessd.darknedgy.net/
>
> developing some systemd compatible services for BSD:
> http://unde
Lennart Poettering writes:
> On Mon, 20.10.14 11:08, Karel Zak (k...@redhat.com) wrote:
>
>> On Fri, Oct 03, 2014 at 07:16:55AM +0200, Jan Synacek wrote:
>> > Karel Zak writes:
>> > >> Karel, any chance you can add a "-o" option to swapon?
>> > >
>> > > No problem, added to TODO. I'll implement
On Tue, Oct 21, 2014 at 11:58 AM, Felix Miata wrote:
> Andrei Borzenkov composed on 2014-10-21 11:29 (UTC+0400):
>
>> Felix Miata wrote:
>
>>> I have 27 Fedora 21 & 22 installations to real hardware, all originating via
>>> HTTP process. Half work as expected. Those that do have NetworkManager not
Hi
On Tue, Oct 21, 2014 at 1:35 AM, Lennart Poettering
wrote:
> On Thu, 09.10.14 19:44, constantine (costas.magn...@gmail.com) wrote:
>
>> Hello all!
>>
>> I am not sure this is the appropriate mailing list, and I have also
>> posted to intel-...@lists.freedesktop.org (without any solution) and
Andrei Borzenkov composed on 2014-10-21 11:29 (UTC+0400):
> Felix Miata wrote:
>> I have 27 Fedora 21 & 22 installations to real hardware, all originating via
>> HTTP process. Half work as expected. Those that do have NetworkManager not
>> installed, and have
>> rpcbind.service
On Tue, Oct 21, 2014 at 10:05 AM, Felix Miata wrote:
> I have 27 Fedora 21 & 22 installations to real hardware, all originating via
> HTTP process. Half work as expected. Those that do have NetworkManager not
> installed, and have
>
> rpcbind.service enabled
>
> Tho
70 matches
Mail list logo
