On 6/2/2016 7:04 AM, Lennart Poettering wrote:
In all of these cases you really want to make sure that whatever the
user did ends – really ends – by the time he logs out.
I apologize if this has already been brought up, but I didn't see this
particular point raised in the replies I've read
Hello all,
While configuring a new Fedora 21 workstation yesterday evening, I ran
into something that I found interesting. I installed Spamassassin,
tried to start it, and got the following entry in the logs:
systemd: Failed at step EXEC spawning /sbin/portrelease: No such file or
On 2/5/2015 16:23, Tomasz Torcz wrote:
SA needs portreserve exactly for the reason portreserve was written:
SA assigned port is 783, and there's a risk portmap will hijack it.
Missing dependency seems like packaging bug.
Thanks for the insight, Tomasz!
Tom
--
devel mailing list
On 2/5/2015 16:21, Kevin Fenzi wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=1175798
I seem to have thought one of my co-maintainers would take care of
fixing this, and perhaps he thought I was going to. ;(
I'll get an update pushed out (or someone will) soon.
Thanks Kevin!
Tom
--
On 2/5/2015 15:58, Reindl Harald wrote:
why in the world does SA need portreserve?
To be honest, I'm not sure that SA is the package that needs it. It is
actually systemd that references it in the spamassassin.service file:
# cat /usr/lib/systemd/system/spamassassin.service
[Unit]
On 10/22/2014 06:31, Lennart Poettering wrote:
It would be great if we could nicely isolate the apps from the OS so
that we can restart the apps independently from the OS, but this
requires isolating things first.
Isn't the differentiation between kernel space and user space sufficient
for
On 10/22/2014 10:58, drago01 wrote:
No the OS is more than just a kernel.
Kernel Space contains more than just the kernel. It also contains
device drivers, kernel extensions, and other privileged processes that
require full system access. User Space exists as a barrier to keep
On 10/17/2014 05:09, Reindl Harald wrote:
on a 56kbit modem you don't want to download the full RPMs and on a
150Mbit line the download will always be faster than rebuild the RPM
Perhaps this has already been suggested, but why not ask a question
during the installation of the OS? For
On 10/17/2014 10:05, drago01 wrote:
Because it makes no sense and pushes it to the user. The os (i.e we)
should handle that. In that case we should do both 1) have lower
bandwith requirements (i.e use deltas) *and* 2) have fast installation
of updates. Those two goals are not mutually
On 10/17/2014 10:43, Rahul Sundaram wrote:
Wile users might be able to handle such questions (I would avoid
calling them stupid even otherwise)
I didn't call them stupid - in fact I suggested just the opposite. Go
back and read what I wrote.
, it is contrary to the goals of the installer.
On 10/17/2014 12:11, Gerald B. Cox wrote:
I think you're setting up a false equivalency here. There is a
difference between the requirements of say an XBOX or Playstation user
and that of updating a Fedora system. If given the choice, most
people will say Yes, I have a high speed
On 10/17/2014 11:29, Rahul Sundaram wrote:
On Fri, Oct 17, 2014 at 11:09 AM, Tom Rivers wrote:
I didn't call them stupid - in fact I suggested just the opposite.
Go back and read what I wrote.
I did. You said My point is that users aren't too stupid to
understand bandwidth/processor
On 10/17/2014 13:19, Rahul Sundaram wrote:
For the last time, my point is that: smart and stupid is not
determined by whether a user understands bandwidth/processor
considerations.
I completely understand that not comprehending all of the complexities
of bandwidth/processor considerations
On 10/17/2014 14:24, Rahul Sundaram wrote:
Deltarpms is again enabled by default in Dnf a while back if you read
the bug report. Everything else has been an tangent, yes.
I suppose I'm having trouble understanding that when you started this
thread with:
On 10/6/2014 04:41, Rahul Sundaram
On 10/1/2014 22:39, Rahul Sundaram wrote:
Since the recent Shellshock aka Bashdoor vulnerability, there have
been some discussions about more distributions switching over...
So there's a vulnerability found in bash, it gets patched almost
immediately, and all of a sudden there's a push to
On 10/2/2014 09:27, Rahul Sundaram wrote:
That is a mischaracterization. Bash will remain the interactive
shell. This discussion is limited to switching the system shell
(/bin/sh) from Bash to potentially Dash.
While I appreciate your technical correction on the scope of this
proposed
On 10/2/2014 09:58, Rahul Sundaram wrote:
I didn't address it because it was not really relevant either. The
impetus is merely the backstory.
On the contrary, the rationale for your proposed change is very
relevant. The reasons for undertaking a project of this magnitude
should be
On 10/2/2014 11:13, Rahul Sundaram wrote:
Sure but the rationale isn't just security as I have explained
earlier. Do read the links and other mails fully.
I have read the emails fully. Sure, I see where you said there were
other reasons later in the discussion, but that's not what your
18 matches
Mail list logo
