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 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 d
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
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 ca
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 s
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 s
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 mo
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 ar
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,
> > > kind
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 questionabl
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
wi
y 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 UNSUBSCRIBE, email to
;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 subje
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 file
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
or systemd
___
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 syst
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
'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
_
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
' 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)
___
--
Don't design like polkit or systemd
___
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 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
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
_
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&#x
'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 sub
st '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 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 t
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)
___
that is a
universal interface'
(Doug McIlroy)
In Other Words - Don't design like polkit or systemd
___
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 i
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, main
__
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' replac
'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? Co
s' 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)
___
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)
_
universal interface'
(Doug McIlroy)
In Other Words - Don't design like polkit or systemd
___
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
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
t '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)
__
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 L
ea 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 Lin
_
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
7;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)
ther Words - Don't design like polkit or systemd
___
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 'ap
___
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'
;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 &q
__
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'
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&#x
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.
> >
> >
design like polkit or systemd
___
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
UX 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-r
ds - Don't design like polkit or systemd
___
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 Li
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 Lin
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.
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
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 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
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
> configure
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
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
> a
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/rc
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,
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 initra
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 a
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.
> >
>
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 th
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 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 o
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
gener
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
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 ;-)
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 s
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 "mana
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 embedde
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 i
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 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 complexi
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 co
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 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 reserve
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 hav
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 (
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%
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 li
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 f
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 commen
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 administra
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 su
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
> > > InaccessibleDir
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 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 u
previously on this list Olav Vitters contributed:
> On Tue, Oct 29, 2013 at 06:37:35PM +0000, 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
> >
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 Deb
previously on this list Cyril Brulebois contributed:
>
> Please refrain from continuing with that kind of chatter. It doesn't
> really help. Quite the contrary.
>
Fine but whether intended upstream or not, it cannot be argued with as
truth.
> (Also, setting an attribution line with the name of
On Mon, 28 Oct 2013 16:40:09 -0400
Paul Tagliamonte wrote:
> Kevin, please change your tone on Debian lists. Your behavior is
> starting to border on malicious. If this continues, I will request that
> you get removed from the Debian lists. I'm sure others would join me.
>
> You're showing a lack
> I'll say no
> more to prevent the usual "Turing Complete" bullshit argument popping
> up but as complex as you choose is a good thing.
And I forgot to say you can choose to make the Linux kernel as simple
or complex as you like so taht's another falsity that he should have
allowed comments to co
1 - 100 of 155 matches
Mail list logo
