On Mon, 12 May 2014 12:00:48 +0200
A debian dev wrote:
Nobody cares.
Please go away.
You apparently don't care that an official debian document is making
sweeping incorrect statements even though I have told you I have
professional experience in this area and pointed debian to a buildroot
previously on this list Steve Langasek contributed:
Yes. This has been the case for su in Debian since 1999, and to do
otherwise would break a variety of configurations where session setup is
required in order for, e.g., the su process to have access to the files of
the target user.
It
previously on this list Russ Allbery contributed:
by the non-stop sniping (for *months* now) by people like Kevin Chadwick,
Well I have only responded to incorrect statements and have tried to
ignore any that are not from debian developers and may not affect the
future of debian but you can't
previously on this list Matthias Urlichs contributed:
I haven't yet seen a system where booting with init=/bin/bash works but
booting systemd in emergency mode does not.
Have you added me to a killfile?
I mentioned such a bug as happened in Arch testing in this very thread
or do you mean a
previously on this list Matthias Urlichs contributed:
Will a script doing this be portable to other Linuxes or even BSD
Unices?
No. BSD has daemon(8). If you want portability, you probably need to check
what's available. (start-stop-daemon, daemon (on BSDs), sudo)
I can tell you
previously on this list Matthias Urlichs contributed:
I also would not expect an end user to add su foo -c /do/whatever to
/etc/rc.local. Your opinion may differ, that's OK.
My opinion certainly does differ as I'm sure is already apparent ;-)
especially that pid1 and single user should most
previously on this list Steve Langasek contributed:
Using systemd breaks something that worked for probably a decade or longer
before however long that su is in that init script. So on what account do
you call calling su in an init script a bug? It may not be the most
elegant solution
previously on this list Simon McVittie contributed:
That would let cautious systemd users keep the
sysvinit binaries around, and boot with init=/usr/lib/sysvinit/init if
something went horribly wrong with systemd.
Not that it would affect me but that would be wise, an upstream bug
caused arch
previously on this list Matthias Urlichs contributed:
Hi,
Kevin Chadwick:
* last but not least: if you do have a tangible reason for your post, i.e.
one of your packages doesn't work with the way systemd is packaged,
kindly tell us which package that is and what you're trying
previously on this list Matthias Urlichs contributed:
Sorry, but I suspect the latter.
Why did I expect any reasonable and balanced discussion! I suspect
but haven't mentioned that I expect the reasons for bundling these
components together to be on highly questionable grounds.
' replacement 'apropos' on Linux is a tool
to help psychopaths learn to control their anger.
(Kevin Chadwick)
___
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
psychopaths learn to control their anger.
(Kevin Chadwick)
___
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https
is a tool
to help psychopaths learn to control their anger.
(Kevin Chadwick)
___
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive
mailing lists
because whilst 'apropos' is traditionally the most powerful command on
Unix-like systems it's 'modern' replacement 'apropos' on Linux is a tool
to help psychopaths learn to control their anger.
(Kevin Chadwick
On Fri, 02 May 2014 10:55:15 +0200
Aaron Zauner wrote:
Bashing on Tor does not help here.
The page suggests all devs use Tor to avoid being targetted.
I am saying, does it accomplish that and is is best practice. Should
they be hackable even if they are targetted or stumbled upon. I find
that
previously on this list Kevin Chadwick contributed:
all sorts of stuff that would make any chroot
in this way pointless. more powerful I expect means less secure in
this usage.
p.p.s. why implement yet more code and complexity into systemd for
preventing device files when you can just use
On Wed, 30 Apr 2014 18:33:56 +0200
Aaron Zauner wrote:
It adds a lot of complexity for privacy benefit. Integrity is often
muddled into security too. As far as I am concerned they can actually
counter each other and are seperate entities.
No they are not. Integrity should be part of
aggressively on LINUX mailing lists
because whilst 'apropos' is traditionally the most powerful command on
Unix-like systems it's 'modern' replacement 'apropos' on Linux is a tool
to help psychopaths learn to control their anger.
(Kevin Chadwick
is a tool
to help psychopaths learn to control their anger.
(Kevin Chadwick)
___
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
On Tue, 29 Apr 2014 00:20:05 +
Jacob Appelbaum wrote:
Tor provides privacy and more likely lowers security so which threat
against contributors or contributor actions is the Tor policy aimed to
protect?
I'm confused, what? How does Tor lower security and at the same time,
it
___
I have no idea why RTFM is used so aggressively on LINUX mailing lists
because whilst 'apropos' is traditionally the most powerful command on
Unix-like systems it's 'modern' replacement 'apropos' on Linux is a tool
to help psychopaths learn to control their anger.
(Kevin Chadwick
is a tool
to help psychopaths learn to control their anger.
(Kevin Chadwick)
___
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
powerful command on
Unix-like systems it's 'modern' replacement 'apropos' on Linux is a tool
to help psychopaths learn to control their anger.
(Kevin Chadwick)
___
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
.
(Kevin Chadwick)
___
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/450827.54193...@smtp120.mail.ir2
.
(Kevin Chadwick)
___
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/246269.70707...@smtp101
On Mon, 21 Apr 2014 10:55:36 +0200
Kurt Roeckx wrote:
I'm not sure what you're trying to say here. But look at the
example of the random number generator in my other e-mail. I've
seen other cases were they do things like that. And I can
perfectly understand why they do it, and then
'modern' replacement 'apropos' on Linux is a tool
to help psychopaths learn to control their anger.
(Kevin Chadwick)
___
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble
___
I have no idea why RTFM is used so aggressively on LINUX mailing lists
because whilst 'apropos' is traditionally the most powerful command on
Unix-like systems it's 'modern' replacement 'apropos' on Linux is a tool
to help psychopaths learn to control their anger.
(Kevin
RTFM is used so aggressively on LINUX mailing lists
because whilst 'apropos' is traditionally the most powerful command on
Unix-like systems it's 'modern' replacement 'apropos' on Linux is a tool
to help psychopaths learn to control their anger.
(Kevin Chadwick
On Fri, 18 Apr 2014 14:57:41 +0200
Aaron Zauner wrote:
Usually the Linux kernel itself provides more than enough entropy. This
can (and probably should) be enhanced but should not be done in a
specific distribution.
I know there has been a little work on the kernel in this area, mainly
lists
because whilst 'apropos' is traditionally the most powerful command on
Unix-like systems it's 'modern' replacement 'apropos' on Linux is a tool
to help psychopaths learn to control their anger.
(Kevin Chadwick
.
(Kevin Chadwick)
___
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/619137.17007...@smtp108.mail.ir2
why RTFM is used so aggressively on LINUX mailing lists
because whilst 'apropos' is traditionally the most powerful command on
Unix-like systems it's 'modern' replacement 'apropos' on Linux is a tool
to help psychopaths learn to control their anger.
(Kevin Chadwick
because whilst 'apropos' is traditionally the most powerful command on
Unix-like systems it's 'modern' replacement 'apropos' on Linux is a tool
to help psychopaths learn to control their anger.
(Kevin Chadwick
psychopaths learn to control their anger.
(Kevin Chadwick)
___
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https
is used so aggressively on LINUX mailing lists
because whilst 'apropos' is traditionally the most powerful command on
Unix-like systems it's 'modern' replacement 'apropos' on Linux is a tool
to help psychopaths learn to control their anger.
(Kevin Chadwick
mailing lists
because whilst 'apropos' is traditionally the most powerful command on
Unix-like systems it's 'modern' replacement 'apropos' on Linux is a tool
to help psychopaths learn to control their anger.
(Kevin Chadwick
mailing lists
because whilst 'apropos' is traditionally the most powerful command on
Unix-like systems it's 'modern' replacement 'apropos' on Linux is a tool
to help psychopaths learn to control their anger.
(Kevin Chadwick
powerful command on
Unix-like systems it's 'modern' replacement 'apropos' on Linux is a tool
to help psychopaths learn to control their anger.
(Kevin Chadwick)
___
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
lists
because whilst 'apropos' is traditionally the most powerful command on
Unix-like systems it's 'modern' replacement 'apropos' on Linux is a tool
to help psychopaths learn to control their anger.
(Kevin Chadwick
___
I have no idea why RTFM is used so aggressively on LINUX mailing lists
because whilst 'apropos' is traditionally the most powerful command on
Unix-like systems it's 'modern' replacement 'apropos' on Linux is a tool
to help psychopaths learn to control their anger.
(Kevin
is a tool
to help psychopaths learn to control their anger.
(Kevin Chadwick)
___
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
previously on this list Bas Wijnen contributed:
On Tue, Apr 01, 2014 at 10:49:15PM +0100, Kevin Chadwick wrote:
I think at Debian we all agree that it would be a good
thing if everything would be encrypted, so this is a very bad outcome.
I beg to differ I'm afraid. SSL should be used
lists
because whilst 'apropos' is traditionally the most powerful command on
Unix-like systems it's 'modern' replacement 'apropos' on Linux is a tool
to help psychopaths learn to control their anger.
(Kevin Chadwick
on
Unix-like systems it's 'modern' replacement 'apropos' on Linux is a tool
to help psychopaths learn to control their anger.
(Kevin Chadwick)
___
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject
aggressively on LINUX mailing lists
because whilst 'apropos' is traditionally the most powerful command on
Unix-like systems it's 'modern' replacement 'apropos' on Linux is a tool
to help psychopaths learn to control their anger.
(Kevin Chadwick
learn to control their anger.
(Kevin Chadwick)
___
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org
mailing lists
because whilst 'apropos' is traditionally the most powerful command on
Unix-like systems it's 'modern' replacement 'apropos' on Linux is a tool
to help psychopaths learn to control their anger.
(Kevin Chadwick
to help psychopaths learn to control their anger.
(Kevin Chadwick)
___
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https
___
I have no idea why RTFM is used so aggressively on LINUX mailing lists
because whilst 'apropos' is traditionally the most powerful command on
Unix-like systems it's 'modern' replacement 'apropos' on Linux is a tool
to help psychopaths learn to control their anger.
(Kevin Chadwick
is a tool
to help psychopaths learn to control their anger.
(Kevin Chadwick)
___
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive
___
I have no idea why RTFM is used so aggressively on LINUX mailing lists
because whilst 'apropos' is traditionally the most powerful command on
Unix-like systems it's 'modern' replacement 'apropos' on Linux is a tool
to help psychopaths learn to control their anger.
(Kevin Chadwick
previously on this list Brett Parker contributed:
Maybe you should do some more investigation, get some better clue of
what you're talking about, and come back with a better, more thought
out, set of arguments that actually have merit.
Right, by arguing on the basis of the definition of Linux
previously on this list Matthias Urlichs contributed:
I did a „setcap cap_sys_ptrace+eip
/usr/lib/nagios/plugins/check_procs”, but a normal user can’t still
check for running programs of another user.
What did I wrong?
check_procs is a script, not a real executable.
Since
previously on this list Matthias Urlichs contributed:
Kevin, I don't think you understand the reasoning behind this. Again,
the problem the init system has to solve here is being able to track a
process with a 100% accuracy, so whatever automated mechanisms you have
configured when
On Fri, 21 Feb 2014 23:53:51 +0100
John Paul Adrian Glaubitz wrote:
Kevin, I don't think you understand the reasoning behind this. Again,
the problem the init system has to solve here is being able to track a
process with a 100% accuracy, so whatever automated mechanisms you have
configured
previously on this list Marco d'Itri contributed:
But you aren't planning on running openrc at all, are you?
Who is? Seriously, would you mind stepping forward?
If it was available I would use it but wouldn't be switching cgroups
on or would be switching them off even if I hadn't bothered
Perhaps before this thread spirals out of control I should re-iterate
that what I said was cgroups doesn't pass the worth-it barrier for me
and not that they have NO value.
I also mentioned pgroups for those that do want this functionality but
also want portability and not bugs in daemons on one
previously on this list Kevin Chadwick contributed:
Perhaps before this thread spirals out of control I should
should also mention this has been discussed on this very list already,
though before I was enrolled and the following response went
unreplied to.
On the other hand and I doubt
previously on this list Matthias Urlichs contributed:
One sample usecase where they dont't: the system is wedged / overcommitted
and I need to terminate some services; guess I'll start another ten processes
to do that. Yeah, right.
I'll be nice to everybody else here and not enumerate any
previously on this list hero...@gentoo.org contributed:
And grepping through the output of ps or similar is not what
I would consider reliable and robust either.
Nod. grepping `ps` is what we should avoid at all cost.
All cost? While I like OpenRC and thanks to Gentoo for it and like
previously on this list Thomas Goirand contributed:
So, systemd is still using /etc/rc?.d. Could you tell exactly what it
uses out of /etc/rc?.d, and what for? Does it only needs to see them as
S??script-name in runlevel 2 or 4 (or whatever it uses...)?
If systemd needs links in /etc/rcX.d,
previously on this list Helmut Grohne contributed:
It's just occurred to me that the binary format may not work with append
only logging?
That's true for the journal. When the journal opens its binary log, it
flags the file as being opened, but what is the issue with not being
append
previously on this list Steve Langasek contributed:
All
software has bugs. The difference is in how you handle them.
And how many!!! AND how many per 1000 lines AND how many run with
priviledges.
--
___
'Write programs
previously on this list Matthias Urlichs contributed:
discussion. No, we should not depend on it for Debian; but we should
provide the interface for system administrators who wish to use it,
because it is not Debian's place to tell them that they cannot use that
interface.
It's not
previously on this list John Paul Adrian Glaubitz contributed:
The problem is that many people who complain about PulseAudio issues
are often prejudiced about it in the first place such that they aren't
actually interested in having the problem fixed but rather just want
to get rid of it and
previously on this list Helmut Grohne contributed:
So for the time being (i.e. until all of my systems and recovery systems
are converted to systemd), I do see a slight[2] disadvantage
It may take even longer until all initramfs will use
systemd (and I do want to read logs from the initramfs
previously on this list Svante Signell contributed:
To answer the original poster's own question, what can he do?
He can stop writing these emails and start writing code (a fork of
systemd supporting kFreeBSD, to be specific)
I don't think forking systemd is a good choice, that
previously on this list Gunnar Wolf contributed:
Everyone knows that the systemd crap is armtwisting and trys to
pull everyone and everything along with it.
Please provide some numbers on this statement of fact. I believe (and
will continue to believe) that the strong supporters of
previously on this list Brian May contributed:
After the damage is done, probably easier to find the malware that did it
Assuming the damage is visible?
All rants aside, I believe there's a fairly wide agreement that we
should throw away binaries from builds.
I'd encourage something
previously on this list Russ Allbery contributed:
One person in particular is currently creating new throwaway
accounts at various free email providers to post violent threats and
invective-filled rants to various project mailing lists.
Maybe it's Lennart and he's hired a psychologist ;-)
previously on this list John Paul Adrian Glaubitz contributed:
You know that you did this before and you apologized to me in private.
If you like, I can post this mail to the public list. You said the exact
same things before and I have heard other Debian Developers who think
the same way
On Wed, 12 Feb 2014 11:25:14 -0500
Paul Tagliamonte wrote:
If they have decided on systemd as default [...]
https://lists.debian.org/debian-devel-announce/2014/02/msg5.html
Can we please end this thread?
Sure but perhaps you could save me the trouble to say if there is a
general
previously on this list Matthias Urlichs contributed:
For instance, a daemon which fails to start under sysvinit will
not even prevent the services which depend on it from starting up.
How terminally stupid is that?
Perhaps you should rethink that whilst considering the
previously on this list Svante Signell contributed:
What I don't get is why are those people trying to push Debian's
decision when they are primarily using a different platform. But I
guess it's pure politics and trying to push their own projects.
I'm pretty sure there are _many_
previously on this list John Paul Adrian Glaubitz contributed:
On 02/11/2014 05:20 AM, Thomas Goirand wrote:
It's like being able to customize internal parts of your cars engine
when ordering one from your dealer. Customers don't care who the
manufacturer of your ignition system is as long
previously on this list John Paul Adrian Glaubitz contributed:
systemd is used as the default init system in:
- Fedora
- Arch Linux
- Mageia
- openSUSE
- SLES (upcoming)
- RHEL7
- Frugalware
- (see Wikipedia)
Plus companies like Intel and BMW are using it in their embedded
On Tue, 11 Feb 2014 20:39:10 +0100
John Paul Adrian Glaubitz wrote:
While they loose the warranty which is my main point.
Who needs a warranty when it's so straight forward. These days you have
an engine with a management system which you have to fix or convince
the mechanic that the
On Tue, 11 Feb 2014 20:37:59 +0100
John Paul Adrian Glaubitz wrote:
Arch, openSUSE and Fedora are among the most popular and widely
used Linux distributions where most of the upstream development
happens.
Show me the numbers, I completely disagree and developers from those
ditributions such
previously on this list Peter Palfrader contributed:
I would really like to standardize on some prefix.
I like _ as a prefix because adduser doesn't allow the local sysadmin to
create accounts with that prefix without special flags, which I think
makes it a more useful reserved
previously on this list Sergey B Kirpichev contributed:
Doesn't matter) rc.local shouldn't be used by local
admin to start services from. Why not use usual init-script?
I wouldn't be surprised if rc.local has been around longer than Debian
and is meant to run at the end. Particularly for a
previously on this list Simon McVittie contributed:
So I'd agree with the underscore but see the not allowing the local
sysadmin to create accounts easily with it as a bad thing as they could
perfectly well want to avoid collisions with packages as much as a
debian dev.
A concrete
previously on this list Russ Allbery contributed:
Just want to mention, I'd really appreciate it if jockey and so polkit
could become an optional dependency of the steam launcher (Ubuntu) and
so I guess steam OS as the Nvidia functionality is not used or needed
when I use steam. Despite Nvidia
previously on this list Roger Leigh contributed:
With an SSD, you really
don't want /tmp or swap on it;
Why?, due to limited write cycles?
As long as it is a modern SSD (years) or one of the old ones one with a
sandforce controller (OpenBSD dev let me know about that) then it has a
good 20%
On Mon, 20 Jan 2014 14:30:24 +
Roger Leigh wrote:
This is a system with 8 cores @4GHz, 16GiB RAM,
over 16GiB swap, so should be pretty performant, yet /tmp on an
SSD made it crawl and freeze continually.
Interesting, have a look if it states the write access time spec in the
datasheet (if
previously on this list Andrew Shadura contributed:
Apparently, you haven't got free disk space left. That's sort of
expected that when there's no free disk space programs start crashing
randomly.
Shouldn't happen if you partition your disks and even then only
carelessly written programs like
It certainly wouldn't be as secure or successful and may not even exist
without OpenBSD.
OpenBSD currently has a shortfall for it's electricity costs and so any
donation's would be much appreciated by the project.
Sorry if you see this as spam it won't happen again.
previously on this list Svante Signell contributed:
Is it true that xpdf is about to disappear. I like that program very
much.
I like it too but it's save dialog is pretty terrible. Have you checked
out mupdf. No save but similar otherwise.
p.s. qpdfview is shaping up and remembers tabs too.
previously on this list Ben Hutchings contributed:
In other words, Canonical gets the right to take a free software
contribution and make it proprietary. The contributors gets to own the
software, and can continue releasing it as free software, but can't
prevent Canonical from making
previously on this list Theodore Ts'o contributed:
So hopefully that is something the technical committee will take into
account --- how well things are documented, both in terms of a
comprehensive reference manual, and a tutorial that helps people with
common things that system
previously on this list Wouter Verhelst contributed:
By absense of documentation, are you referring to the almost 10% of the
source base that are comments or the 15% that is DocBook XML based
documentation? (Almost 14kLOC and almost 36kLOX, respectively.)
That particular comment was
previously on this list Zbigniew Jędrzejewski-Szmek contributed:
Hi Helmut,
exec vs. ExecStart= and export vs. Environment= is easy.
Anyone can whip up a sed script to convert between those. The question
is how to deal with more advanced options. Let's say that I have a
systemd unit with
previously on this list Helmut Grohne contributed:
Most participants in this thread appear to agree that the sysvinit
*interface* for services (shell scripts) is suboptimal.
Not so sure, I have various thoughts on this and even the reasons that
it is considered sub optimal but think some like
previously on this list Jonathan Dowland contributed:
Couldn't they just be ignored not to mention already having existing or
far more functional and robust *options* that work with any init system.
A cursory glance at the example above…
PrivateTmp=yes
previously on this list Russ Allbery contributed:
Well I meant that they would be used by systemd and ignored likely
noisily by default by others. However this really should be the job of
the service in any case as depending on a third party service for
security that isn't extra such as
previously on this list Philipp Kern contributed:
I'm not sure why our enterprise users don't count as users as well.
Of course they do even if the couple of people possibly concerned with
it that I know use.. is it Citrix? I was merely pointing out that it
is an extremely small minority of
previously on this list Olav Vitters contributed:
On Tue, Oct 29, 2013 at 06:37:35PM +, Kevin Chadwick wrote:
Of course they do even if the couple of people possibly concerned with
it that I know use.. is it Citrix? I was merely pointing out that it
is an extremely small minority
you need something with big buttons
that is finger-friendly,
I'm surprised how much accuracy a capacitive multitouch mobile has when
in touchscreen terms it is actually extremely poor (3-4mm) exacerbated
by them not responding to nails (conductive), a trade-off for size and
multitouch. Many
OK. I suggest that we *try* that for now.
If we try, what will be the criteria for assessing whether the
experiment has been successful (and hence worth keeping for Jessie) or a
failure (and hence reverting it)?
I think it should be considered that there has been much improvement
upto
E.g. XFCE either wants ConsoleKit, or logind. If you look at ConsoleKit,
you'll notice it is NOT maintained.
XFCE *needs* neither and in fact the vast vast majority of users do
not either.
I check the spec files for Fedora, Mageia, openSUSE. They all seem to
require logind.
1 - 100 of 155 matches
Mail list logo