disk as before,
simply to make things simple so that people can optionally do both:
store the verification key offline *and* in TPM, and if the TPM is
lost they can still use the verification key they stored elsewhere)
Lennart
--
Lennart Poettering, Berlin
__
_users(), since that spawns off a child process which then
> goes and writes to /proc/$parent_pid/, but I guess children can ptrace
> their parents? At least it seemed to work when I just tested it.
On traditional Linux any ptracable means "uid matches". With yama lsm
parents can ptrce t
mething I don't like. Semantically it's only
marginally better than just creating a new file from scratch.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
o not
> defragment unless it's SCSI/SATA/SAS and it reports it's rotational.
btrfs itelf has a knob declaring whether something is ssd or not ssd,
configurable via the mount option. Of course, one would bind any
higher level logic to that same thing, and thus make it btrfs' own
problem, or the
ut a
really low-level system thing, hence you might get warnings about
this.
You can of course mask sys-fs-fuse-connections.mount too.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
worth it.
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
timized for access times, not for minimal iops.
I'd be totally open to revisit this all, and take iops more into
account, but again, we'd need a bit of profiling that compares access
times, iops, and stuff with and without this, on rotating and ssd.
Lennart
--
Lennart
that other mail could have a special value besides yes/no
of "ssd" or so, where we'd use btrfs own understanding if it's backed
by ssd or rotating media, as controlled with the ssd/nossd mount
option. (though ideally we'd have a better way to query it that to
parse out the mount
On Fr, 05.02.21 17:44, Chris Murphy (li...@colorremedies.com) wrote:
> On Fri, Feb 5, 2021 at 3:55 PM Lennart Poettering
> wrote:
> >
> > On Fr, 05.02.21 20:58, Maksim Fomin (ma...@fomin.one) wrote:
> >
> > > > You know, we issue the btrfs ioctl, under the
ia. Apparently noone
who cares about this apparently wants to do such research though, and
hence I remain deeply unimpressed. Let's not try to do such
optimizations without any data that actually shows it betters things.
Lennart
--
Lennart Poettering, Berlin
___
On Fr, 05.02.21 16:16, Phillip Susi (ph...@thesusis.net) wrote:
>
> Lennart Poettering writes:
>
> > Nope. We always interleave stuff. We currently open all journal files
> > in parallel. The system one and the per-user ones, the current ones
> > and the archived ones.
t a new file before the old one is full?
Various reasons: user asked for rotation or vacuuming. because
abnormal shutdown. becase time change (we want individual files to be
montonically ordered), …
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
On Fr, 05.02.21 16:06, Dave Howorth (syst...@howorth.org.uk) wrote:
> On Fri, 5 Feb 2021 16:23:02 +0100
> Lennart Poettering wrote:
> > I don't think that makes much sense: we rotate and start new files for
> > a multitude of reasons, such as size overrun, time jumps, abn
On Fr, 05.02.21 10:24, Phillip Susi (ph...@thesusis.net) wrote:
>
> Lennart Poettering writes:
>
> > You are focussing only on the one-time iops generated during archival,
> > and are ignoring the extra latency during access that fragmented files
> > cost. Show me tha
On Do, 04.02.21 12:51, Chris Murphy (li...@colorremedies.com) wrote:
> On Thu, Feb 4, 2021 at 6:49 AM Lennart Poettering
> wrote:
>
> > You want to optimize write pattersn I understand, i.e. minimize
> > iops. Hence start with profiling iops, i.e. what defrag actually cost
On Mi, 03.02.21 23:11, Chris Murphy (li...@colorremedies.com) wrote:
> On Wed, Feb 3, 2021 at 9:46 AM Lennart Poettering
> wrote:
> >
> > Performance is terrible if cow is used on journal files while we write
> > them.
>
> I've done it for a year on NVMe. The
s worth it: i.e. that leaving the
files fragment doesn't hurt access to the journal badly, and that the
number of iops is substantially lowered at the same time.
The thing is that we tend to have few active files and many archived
files, and since we interleave stuff our acces
On Mi, 03.02.21 22:32, Chris Murphy (li...@colorremedies.com) wrote:
> On Thu, Jan 28, 2021 at 7:18 AM Lennart Poettering
> wrote:
> >
> > On Mi, 27.01.21 17:19, Chris Murphy (li...@colorremedies.com) wrote:
> >
> > > Is it possible for a udev rule to have a tim
eat if we could turn datacow back on once the files are
archived, and then take benefit of compression/checksumming and
stuff. not sure if there's any sane API for that in btrfs besides
rewriting the whole file, though. Anyone knows?
Just dropping FS_NOCOW_FL on the existing file doesn#t work iirc, it
can
entation is
really too high.
But quite frankly, this sounds polishing things after the horse
already left the stable: if you want to optimize iops, then don't use
btrfs. If you bought into btrfs, then apparently you are OK with the
extra iops it generates, hence al
certainly still optimize stuff (i.e. "systemctl daemon-reload" is
expensive), but things to my knowledge having a few K of units should
be totally Ok. (But then again I don't run things like that myself, my
knowledge is purely based on feedback, or the recent lack thereof)
Lennart
--
Lennart
On Di, 02.02.21 11:46, Alan Perry (al...@snowmoose.com) wrote:
>
> On 2/2/21 1:55 AM, Lennart Poettering wrote:
> > On Mo, 01.02.21 16:36, Alan Perry (al...@snowmoose.com) wrote:
> > > Hi, Per the udev rules, the blkid builtin is run on mmcblk*boot*
> > >
On Di, 02.02.21 22:50, Andrei Borzenkov (arvidj...@gmail.com) wrote:
> 02.02.2021 17:59, Lennart Poettering пишет:
> >
> > Note that Requires= in almost all cases should be combined with an
> > order dep of After= onto the same unit.
>
> Years ago I asked for exampl
f the
usual workflow.
Note that Requires= in almost all cases should be combined with an
order dep of After= onto the same unit. If the unit above doesn't do
that it's almost certainly broken.
Lennart
--
Lennart Poettering, Berlin
___
). It will not show you anything that is from the
unit file that is masked. Which is kinda the point of masking: hiding
away the original unit file, and making sure systemd (or systemctl
cat) won't use them for anything.
Lennart
--
Lennart Poettering, Berlin
___
oesn't find anything, so not much bad
happened?
If this matters to you, and it's really clear that there is unlikely
anything blkid-recognizable on it, then by all means, please send a
PR!
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel ma
d in that it needs — just creates the socket itself as a
fallback...
It's generally a good idea for services to have Requires= + After= on
the sockets that actviate it, to make sure that the sockets are always
started before the service itself, and the situation you are seeing
can
known
> up-front, before the first install, but be somehow tied to the machine's
> hardware. So that's what we did.
Write it from the initrd.
You can also set it via a kernel command line option. There was also
the idea of initializing it from an env var passed t
│ └─854319 (sd-pam)
> └─syncthing.service
>
> exists and gets auto started by "systemd" without any asking really.
> This is really very bad, no?
> What am I missing here?
systemd at the very least will spawn your per-user dbus daemon, which
is needs to be avail
it possible you are playing some weird games with your machine ID
or boot ID?
journalctl by default only shows messages matching either the current machine ID
or the current boot ID. (the latter since the initrd will have a
different machine ID than the host)
Lennart
--
Lennart Poette
Rebooting.
> [ 1670.211839] kvm: exiting hardware virtualization
> [ 1671.457978] reboot: Restarting system
> [ 1671.461965] reboot: machine restart
> ~~~
The logs above suggest dracut does kexec in your case, not systemd?
Lennart
--
Lennart Poe
68372627
systemd/udev has no clue about btrfs superblocks. It only talks to
libblkid, and to the kernel. It doesn't parase anything on its own. If
you want this property to be attached to the udev device, please
request this from the libblkid maintainer, since we basically impo
On Do, 28.01.21 10:08, Martin Wilck (mwi...@suse.com) wrote:
> Hi Lennart,
>
> thanks again.
>
> On Wed, 2021-01-27 at 23:56 +0100, Lennart Poettering wrote:
> > On Mi, 27.01.21 21:51, Martin Wilck (mwi...@suse.com) wrote:
> >
> > if you want the initrd envir
correctly to /var but journalctl appears to read from
> /run.
journalctl reads from both dirs, always. What makes you think it reads
from the wrong dir only?
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
syste
OLLPRI is the right API. inotify is used by cgroupfs
for similar notifications, and I mixed that up. for
/proc/self/mountinfo POLLPRI is the right choice.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
On Di, 26.01.21 13:30, Martin Wilck (mwi...@suse.com) wrote:
> On Tue, 2021-01-26 at 11:30 +0100, Lennart Poettering wrote:
> >
> > > Imagine two parallel instances of systemd-udevd (IMO there are
> > > reasons
> > > to handle it like a "root storage dae
fork our stuff, or just use our
stuff, it's Free Software after all.
Either way, please contact the maintainers of your distro and
"elogind" for help in general, this is the wrong forum for such
questions.
Lennart
--
Lennart Poettering, Berlin
___
On Di, 26.01.21 01:19, Martin Wilck (mwi...@suse.com) wrote:
> On Mon, 2021-01-25 at 18:33 +0100, Lennart Poettering wrote:
> >
> > Consider using IgnoreOnIsolate=.
> >
>
> I fail to make this work. Installed this to the initrd (note the
> ExecStop "command&
le one can do
> > about that.
>
> Why would it be so bad? I would actually prefer a single instance for
> most subsystems. But maybe I'm missing something.
Well, because you can't update things on-the-fly then, you cannot
reexec since everything is backed by initrd. You cannot restart
one: have two unit files? i.e. two instances of the subsystem,
one managing the root storage, and one the rest.
option two: if you cannot have multiple instances of your subsystem,
then the only option is to make the initrd version manage
everything. But of course, that sucks, but there's little
t; Is it possible to somehow remove the "sleep 1"?
>
> For details see:
> https://github.com/eriksjolund/user-systemd-service-actions-workflow
https://github.com/systemd/systemd/pull/17967
Lennart
--
Lennart Poettering, Berlin
___
s
hen our
builds kinda required it). If this is important to you I'd suggest
open a feature about it, any ping @mrc0mmand about it (he's our CI
go-to guy).
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
i/LTOByDefault
(I think Suse is even further ahead on this)
So, it's up to you where you want to take things, but I sense the
future is "yes to LTO" and not "no to LTO".
Lennart
--
Lennart Poettering, Berlin
___
systemd-dev
reference clock. This is a much stronger
option, but means the boot process will be delayed based on network
availability.
Coincidentally we documented this recently in more detail, see git
commit b149d230ea23c14bac2dfe79c47e58782623200f which also will be in
the nex
system service, if this is a
> > kiosk system, maybe you can use it instead.
>
> Thank you for the reply. There are security risks running pulseaudio
> in system mode[1].
Well, but what you are doing is worse, you reverse the layers of the
stack...
If you want a system s
sr/bin/killall --user kodi --exact --wait kodi-gbm
> Restart=on-abort
> StandardInput=tty
> StandardOutput=journal
>
> [Install]
> Alias=display-manager.service
This is not a supported setup. System services should not be clients
to per-user services. The opposite
ne-id
Most likely something has that file open still.
Maybe turn on debug logging ("systemd-analyze log-level debug") and
check logs on next boot, and check what the precise error was.
Lennart
--
Lennart Poettering, Berlin
___
systemd-deve
nt. Everyhing can. But
humm, the docs don't need "fixing", they aren't broken. They suggest
exactly what to do.
Happy to review/merge a patch that improves things, but I think the
brokeness you two imply is just not there.
Lennart
--
Lennart Poettering, Berlin
___
Hence contact your downstream distro about this
instead, they can help you.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
istic (or may be it is but then it is always "wrong" for
> > your purpose :) ), so in your case job for Second runs too late, when
> > Third is already started and there is no pending job to fail.
>
> Ah. Thanks for the explanation. Adding
>
a
unit is in the job queue or it isn't, the distinction between jobs and
units is very technical, and if you ask me not too relevant for
readers.
Hence, I don't agree with your criticism. Insisting on the existance
of the job concept to explain ordering deps doesn't help.
Lennart
--
Lennar
t
Add "After=first.target second.target" here as well. Ordering and
requirement deps are orthogonal in systemd. See documentation.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
ted? i.e. the activation of service 1 and 2 need to happen first
and they are the trigger for service 3, but besides that noone ever
asks for service 3?
If so, it appears to me a Wants= dep from services 1 and 2 on 3 would
make sense, plus a Requisite= dep in the other direction.
Lennart
--
Lennart Poettering
t; issues.
Have you read the docs about ExecStop=?
Note that ExecStop= is only run once the service managed to complete
initializatio at least once, i.e. ExecStart= complete fully so that
the service is up.
Maybe turn on debug logging (with "systemd-analyze log-level debug")
to get a clos
way, I'd recommend you to try it out and see if it fixes your
CI problems? That's the only way you can now for sure...
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
can't restart libvirtd-tls.socket when libvirtd.service is
> running: I first have to stop libvirtd.service.
This really depends on how the libvirt object put together its unit
files, and cannot be answered out of thin air.
Not sure what "configured TLS later" is even suppo
development headers to be installed during
build.
Also note that your kernel needs to enable iptables (not nftables) for
this to work.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://list
cted to the AT keyboard
controller, and yours is connected to a serial port, right? So the
udev rules should be fixed to match against the former only.
Anyway, please file a PR/issue on github about this, and continue the
discussion there.
Lennart
--
Lennart Poettering, Berlin
__
oing to customize it anyway then maybe /etc/fstab should
> be that config file? Instead of gpt-generator, why not make udev create a
> "/dev/disk/by-purpose/efi" symlink and use that as the fstab device...
> Would that technically work?
That is in fact a great
ier boot. It's what the systemd-udev-trigger.service unit is
> > doing.
> >
> > Triggering means all udev rules are run again.
> >
> > Lennart
> >
> > --
> > Lennart Poettering, Berlin
> >
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
this be configured?
No, it cannot.
But you can use $EXIT_CODE, $EXIT_STATUS and $SERVICE_RESULT env vars
in ExecStop= that tell you what happened. Thus you can write a script
wrapping your stop command that determines what to do.
Further details on these env vars are on systemd.
tically at boot, in order to
"coldplug" devices that have been found by the kernel already during
earlier boot. It's what the systemd-udev-trigger.service unit is
doing.
Triggering means all udev rules are run again.
Lennart
--
Lennart Poettering, Berlin
__
alid or is using `..` something that
> shouldn't be possible?
No, that's OK, we do that from time to time too. Of course, I'd avoid
it unless there's no better way to match the device. i.e. if you can
recognize a device by its own properties it's typically much better
than rec
k to us if this
is still a problem in current versions.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
work for you. (or even better, hack it up,
provide a patch).
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
On Fr, 27.11.20 23:18, Gena Makhomed (g...@csdoc.com) wrote:
> How to fix or workaround this problem with default route?
Have you looked at networkd's logs?
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-de
worse btw, since the write pattern we employ
that are very unfriendly to CoW file systems (i.e. we do random
writes; CoW file systems can't really handle anything that aren't
linear writes). In upstream defaults we thus turn off cow for these
files, not sure if your distro undoes that tho
used, others are not. It
could certainly use some love to make it round again though.
It's too good to remove I'd say. I'd rather see the thing fixed (work
on that would be minor I guess), and a test added so that it doesn't
regress again.
Lennart
--
Lennart Poettering, Berlin
invocation is randomly generated whenever a new start cycle begins.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
On Di, 10.11.20 12:47, Arian Van Putten (ar...@wire.com) wrote:
> I think what you might want is `Type=exec` instead of `Type=simple` in your
> unit file. It was recently added to systemd.
Recently? That was in 2018! 2 Years ago!
Lennart
--
Lennart Poettering,
tc/fstab i#d recommend:
1. in your initrd fsck the root fs first
2. then mount it in the initrd, and mount it writable right away
3. remove /etc/fstab
4. systemd-remount-fs will notice that the file is absent, and not do
anything. (You could even mask the service if you like)
Lennart
--
Lennar
ILE_SIZE_INCREASE define in journal-file be runtime configurable,
> and/or clamped by the existing size limits.
Yeah, making this value configurable certainly makes sense. Please
file an RFE issue on github.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
tive files will stay around. This
means that, in effect, there might still be more journal files
around in total than this limit after a vacuuming operation is
complete. This setting defaults to 100.
Lennart
--
Lennart Poettering, Berlin
__
of it there?
(We probably should convert that text into markdown anyway, and
maintain it as part of the git repo).
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
on github?
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
probably might not matter too much there to fix the
action guards. It would still be much prettier, more correct if they'd
use ACTION=="remove" though.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
o nice way. Depends on the subsystem.
You could start by going through the udev rules files of your
distros. 95% of the rules files that use a guard different from
ACTION!="remove" are possibly broken, or at least ugly (and not future
proof).
Lennart
--
Lennart Poettering, Berlin
_
a ref?
Please provide a minimal example where the issue is supposed to show.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
your OS? /var should be writable at the point the
rfkill service is started. i.e. it comes with an ordering dep on
After=systemd-remount-fs.service and a line
RequiresMountsFor=/var/lib/systemd/rfkill which make sure /var/ must
be mounted and writable by then.
Lennart
--
Lennart Poettering, Berli
e. If that's not the case
for you, this would probably be a bug. Please file an issue on github
about this then.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
s0
>
> WLANInterfaceType="mesh-point"
>
> It doesn't want to match even though wlp6s0 is currently connected to my
> mesh.
Give this looks like a bug, please file an issue on github about this please.
Lennart
--
Lennart Poettering, Berlin
_
we can translate users 1:1 without loss.
Or in other words: this part is still work in progress...
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
> Is this the correct command? This seems to be not documented.
We have nothing better right now. i figure we should add "pstorectl"
or so, matching "coredumpctl" and "journalctl".
Please file an RFE issue on github about
Maybe we
need to extend BindREadOnlyPaths= so that it takes a bunch of files as
bind mount sources and uses the first one that exists or so. It
wouldn#t be perfect though, given that this would handle only cases
where resolved is not installed, not the ones where it is installed
but disabled.
Ca
couldn't be bothered to
revert to that. I have the suspicion Docker is generally considered
legacy software at this point, and the reimplementations (podman, …)
are probably the better replacements to focus on.
Lennart
--
Lennart Poettering, Berlin
___
systemd-de
sue #3700?)
I think some people noticed this so far, but noone actually cared
enough to do anything about it. I guess few people were actually
missing it.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
ht
the kernel already
exposes this, we can certainly expose this as dbus property too. Plese
file an RFE issue on github about that if so.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://li
e using.
Are you using this in --user or --system mode? (Note that a bunch of
sandboxing settings are only available for --system).
Have you checked the logs? In particular after enabling debug logging
(systemd-analyze log-level debug).
Lennart
--
Lennart Poettering, Berlin
_
unit into
multi-user.target. This then means that the service will be started at
boot, but before it can actually be activated, the tap0 device has to
show up. Key here is that the Wants= pulls the .device unit into the
job queue, and thus can be waited on.
Lennart
-
something fnmatch(3) nor glob(3) support,
hence tmpfiles.d/ doesn't either.
I this is something worth supporting it probably needs support in
glibc first. I'd rather not like to deviate from glibc behaviour here.
Lennart
--
Lennart Poettering, Berlin
ows to address certain forms of starvation. It's not used for
journald yet. Please file a bug on github about this if current
journald versions still show this behaviour for you, and we can look
in making use of this to make the sync stuff eventually complete even
if journald is under load.
Lennart
-
t? DNS updates?
If you mean DNS updates, we do not support that currently, and noone
is working on that.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
log all system calls that are done by a service.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
s is messy and generally not portable. If you
care about portability maybe go the RLIMIT_NOFILE way, which is of
course terrible inefficient, but that's the price you have to pay for
portability I guess.
Anyway, I don't think mentioning /dev/fd/ is generally helpful, it's
misleading at best I thi
e everyone use either ed25519 or PKCS#7 for this.
Looking forward to your patches ;-)
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
t I
am asking for here: if anyone actually cares about gnutls/gcrypt
support and what the reasons for them are.
I want something stronger than "I like" and "I dislike". I want to
hear technical, or legal reasons. Not "taste".
Lennart
--
Lennart Poettering, Berlin
_
e
counting on this to resolve the licensing situation around crypto
libraries. Due to the Debian change I figure we can speed up things
now, though.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop
ev rules
> processing performance.
Replied there now.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
really curious if a iouring based reader could outperform the
mmap based ones. I have the suspicion that yes, since paging in stuff
is slow, and doesn't really allow for reordering.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing lis
d[1]: Failed to start The Apache HTTP Server.
Maybe there's more info the apache logs?
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
601 - 700 of 8632 matches
Mail list logo
