> since some people might not read planet debian, here is a link to my
> third blog post in a series of posts dealing with the results of the
> Debian systemd survey:
Well I am behind on my mailing list reading just at the time when it
matters for my concerns for debian. I disagree with many of th
> > It might help if we used a bit more precision in terimonolgy. "Not a full
> > blown MTA" as described here is a Mail Submission Agent (MSA). See RFC
> > 5598 for details:
OpenSMTPD has quite recently been released for production and is rather
good and worth adding to the review list.
http:/
> olivier sallou writes:
> > hi,
> > I need for a package to override some udev standard rules.
> >
> > If I put an identical rule name in /etc/udev/rules.d, I know it overrides
> > the one in /lib/udev/rules.d
> >
> >
> > However, lintian raises an error if I put an udev rule in /etc instead of
>
My point of view is that Debian Stable should be aiming for whatever
they believe the sweet point between stable and so usable without having
problems is and maximising security. Aka maximising productivity and
safety with no other concerns or compromises.
Large hosting companies not having made t
> There is no point to start a daemon unless you actually
> need it.
This is complete 'modern' crap
If you don't want a service started then why are your starting it,
because you might want it is a stupid argument with next to no
positives. SSH takes a blink of an eye to start.
It is far better
> On Aug 23, 2013, at 8:45 PM, James McCoy wrote:
> >
> >> On Fri, Aug 23, 2013 at 04:42:15PM -0400, John Paul Adrian Glaubitz wrote:
> >> Imagine there is a vulnerability in SSH which has not been fixed
> >> yet for whatever reason. Having SSH run in this situation all the
> >> time would make t
> > Large hosting companies not having made their scripts etc. good enough
> > to ride out upgrades well should have nothing to do with any decision.
>
> I don't think the problem here is with "Large hosting companies not
> having made their scripts etc. good enough". I don't think it has
> anyt
> Alternately, we could be far more aggressive about removing packages from
> oldstable, I suppose, but I don't think that's a good idea; that just
> leaves our users with exactly the sorts of choices that we're trying to
> avoid. I think it's much cleaner and better for our users to offer full
>
> Like much of systemd it may seem impressive at first on the face of it
> but actually holds little value or doing what are already optional
> functions and has not been thought through or come from any great
> experience.
It has since occured to me that it was alleged on the Gentoo list that
the
> In that light the memory saving trade off for security and practicality
> actually makes sense as you could save lots and lots of resources on a
> massive server or server farm running hundreds or thousands of server
> systems per machine etc..
Unless someone conjures up a targeted attack (pleas
> I wasn't clear, I don't mean you'll do each one as a special snowflake
> in-place. I mean, 20,000 machines is simply a lot of machines to
> manage. No matter what, upgrading or replacing the OS all within a 1
> year schedule that you do not control and cannot fully predict, is a
> big hassle.
W
> "Upgrading is easy" is not really a valid retort. Though it does mitigate
> the cost, it does not eliminate it. Nobody wants to spend their automation
> budget on making upgrading easy enough to do on a whim. There are plenty
> of other concerns that automation must address that have nothing to d
>xxxterm: bugs 718074, flagged for removal in 8.3 days
I use debian offline so it is of no consequence to me however I
just wanted to say.
xxxterm (now xombrero) is by far my favourite browser and rediculously
faster than any other browser whilst still being highly useful and with
better whit
> I have to join Marc here and say "me too". In my organisation we
> actually have those controls in place (antivirus/antimalware) in the
> Internet gateways and we do not disable them for specific traffic
> flows unless a detailed risk analysis has been done (and approved).
Personally I disagree
> You can disagree with this approach. However, in my 10+ experience
> setting up security gateways for Internet traffic (mostly for
> HTTP/FTP/SMTP) I've seen only a few vulnerabilities in the gateways
> themselves. Many of the gateways I have deployed are either network
> appliances with a Commo
> XFCE is short of maintainers, both upstream and debian, but 4.12 is
> expected to be released sometime in the next 6 months. That said,
> everything both debian and upstream is stable, and a number of 4.11
> "development release" packages are able to be uploaded to experimental
> if more people c
> > Why should I have installed packages I'm not using and I don't want to
> > use? I know it's rhetorical question but not all systems are having
> > enough disk space besides I don't like have packages I'm not using on
> > my systems. So it's not a solution to anything just kind a nasty
> > wor
> For people who just don't care, are you doing them a favour by installing
> xfce rather than GNOME?
>
> I don't think so. Most of the things people hate about GNOME are things that
> GNOME is doing to specifically target people who just don't care.
Personally I wouldn't put Gnome 3 in front of
> Pros:
>
> * CD#1 will work again without size worries
>
> * Smaller, simpler desktop
>
> * Works well/better on all supported kernels (?)
>
> * Does not depend on replacing init
* Users can pick and choose components and drop down the size
significantly such as for debian embedded or s
> > I believe that systemd/GNOME upstream is intentionally coupling the two
> > in order to force adoption of systemd. There are obviously others who
> > do not believe this. If it is true, however, I would consider it
> > sufficient justification to both change Debian's default DE and
> > elimin
> * it is buggy. I did install a straightforward install of experimental
> GNOME to test if it improved even a bit, running systemd as init, and, with
> 2G RAM assigned to the machine, I got an OOM from one of systemd's
> components. Excuse me for not looking more closely but purging the machine
> without being micromanaged in what they put into their dependency
> fields.
That's an odd comment as the dependencies should ideally be the very
minimal that are absolutely required. (I understand it may not be
always easy)
--
___
> I'm fed up with repeated attempts to force components on the rest of the
> system, but that's mostly a fault of Gnome's upstream
There seems to be a trend emanating from packages involving RedHat devs.
I actually went to the RedHat site a few weeks ago to try and get some
sort of oversight on th
> This is a move to SABOTAGE linux as an OS.
I have to admit if RedHat stuck to kernel work, I would be much
happier.
--
___
'Write programs that do one thing and do it well. Write programs to work
together. Write programs to
> 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.
--
___
'Write programs that do one
> You're aware that GNOME and systemd upstreams are two completely
> distinct groups
But they do both have strong redhat links, coincidence or not.
--
___
'Write programs that do one thing and do it well. Write programs to work
> Of course, the gnome default makes adding gnome to the plot not
> currently useful. One nice side benefit of at least temporarily
> switching the default desktop to xfce would be that if a lot of people
> wanted gnome, rather than just picking it as the default, we'd see that
> reflected in the p
What can be done to prevent rather than reacting to dependency hell all
the time. Some developers obviously get it and yet others seem to
pro-actively work in the other direction.
There was a time when it was said that this problem was finally heading
in the right direction.
There is an example t
> "Session tracking" includes suspending/hibernating, because logind has
> a mechanism to let apps delay suspend, which is necessary for things
> like closing the inherent race condition in "lock the screensaver when
> we suspend... oh, oops, it didn't get scheduled until after we
> resumed, so the
> Steve Langasek has been consistently posting dishonest FUD against
> systemd. Maybe you could explain that as excessive zeal following from
> valid technical considerations, but I'd consider that an excessively
> charitable interpretation for a member of a body that is supposed to
> have public t
> I recommend one more option, nicknamed "rotten tomatoes",
> that basically says that this GR should never have been proposed.
And even more so not listened to for a few reasons.
Little has changed since the last discussion that I feel came to a
reasonable current standing with an overview pos
> But that alone is not an argument against introducing new technologies.
> One just has to be careful in what is done.
Not against new technologies in general but if you are talking about
something which you expect every Linux user to use (when actually they
can't in deep embedded etc.) then yes
> My understanding is that the _kernel_ side wants to change the cgroup
> API, and this means that at least in the long term current cgroup-using
> applications will need to change in any case (possibly by using systemd
> APIs instead). I'm not familiar with the specific case of lxc, but I
> really
> systemd doing more is quite relevant for this decision as far as I
> understand the discussion: unlike upstart, systemd is not just an init
> replacement, but offers additional services like journald or logind.
I don't mean to be rude but please read up on systemd and see the pros
of cons such a
> If I'm not mistaking (please correct me), Fedora has the feature, and
> it's been a long time they do. FreeBSD as well (they have unbound in the
> default installer). OpenBSD also removed bind and switched to unbound
> (or at least is planning on doing it, I'm not sure). Debian shouldn't be
> lef
> On Sat, Oct 26, 2013, at 18:58, Kevin Chadwick wrote:
> > I believe the reliability (DOS) issues that DNSSEC imposes coupled with
>
> Please, not this again. If you say DNSSEC DOS issue, you must state all
> the other issues that DNS has.
>
Not really, the security issue
> > * Gnome is said to work fine even on platforms that don't have
> > systemd installed.
> My understanding from what I've read is that it "works fine" except in
> that the features which the ConsoleKit-or-logind dependency provides
> aren't available. That's derived from indirect statements fro
> 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
up
> > > 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
> requ
> So, as per the replies we've read, it seems that the only way to
> implement DNSSEC would be to first check if it works, and if it doesn't,
> fallback to the locally provided recursive DNS server.
I still think a switch on/off (whatever the default) should be
considered because if anyone decides
> since that will help our non-Linux
> ports
and embedded Linux, especially deep embedded systems such as cortex and
blackfin which is coming along fairly nicely too.
--
___
'Write programs that do one thing and do it well. Wri
> >
> > IANA ftp-master, but here's my quick review:
> >
> > Please rename /sbin/rc to something else. We've had (unrelated)
> > /usr/bin/rc in Debian for at least 18 years.
>
> Outch! This bites hard. Maybe you being the maintainer of the "rc"
> package is why you saw this immediately! :)
>
> You said vast vast majority, you do the work! At the moment it seems
> you're just changing goalpost as you go along.
Not at all. I meant functions of a desktop that the average users use
all along.
So the vast vast majority of users such as laptop users do not need
session tracking but may wan
> > >For those who haven't seen it, Lennart has posted some of his comments
> > >about all this on G+:
> > >https://plus.google.com/u/0/115547683951727699051/posts/8RmiAQsW9qf
> >
> > And the RH PR circus has already started around it.
> >
> > Lennart's g+ note is written in his usual half-trut
Please lets see what is around the corner before giving merit to
these scare tactics especially for a Gnome desktop whose user base has
and is rapidly declining.
--
___
'Write programs that do one thing and do it well. Write pr
> 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
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
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
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 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 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 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
> > > InaccessibleDir
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 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 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 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
Anyone else get a Knotify crash on startup on Debian 7 but only if all
power has been removed during shutdown?
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2013040
> > And how would I use it on Debian when there is no Internet Explorer 7
> > available for non-Windows platforms? Wine?
>
> The purpose is to provide a web thingy, hosted on a Debian platform,
> that even clients behind a legacy browser from non-free distribution can
> see as they should if the
> For instance, one of the (ugly) boxes I help admin recently
> had 1000 pacakges yet to update and > 60 security packages not done, and not
> enough space on the box to do them.
Aptitude installs all recommended packages by default which was rather
annoying until I found that in the options me
> > Aptitude installs all recommended packages by default which was rather
> > annoying until I found that in the options menu as I ran out of space a
> > couple of times.
>
> as does apt-get.
I'm fairly sure synaptic doesn't select recommended by default, however
the synaptic package itself is
> > > Aptitude installs all recommended packages by default which was rather
> > > annoying until I found that in the options menu as I ran out of space a
> > > couple of times.
> >
> > as does apt-get.
>
> I'm fairly sure synaptic doesn't select recommended by default, however
> the synapt
> Please take your FUD elsewhere.
>
> It's an implementation of the JavaCard specification. It's not
> something that runs in your web browser, but they're both called
> applets.
Does it require a JRE to be installed (which the security community
avoids for good reason), if so then it does reduc
> > > Please take your FUD elsewhere.
> > >
> > > It's an implementation of the JavaCard specification. It's not
> > > something that runs in your web browser, but they're both called
> > > applets.
> >
> > Does it require a JRE to be installed (which the security community
> > avoids for good
http://superuser.com/questions/95509/tell-aptitude-to-ignore-broken-package
Does this work and is aptitude the best way to update whilst ignoring
incorrect or even debatable dependencies or can apt-get do so too.
Is equiv a fast and easy solution?
Currently I am getting fix broken on steam-laun
> your question is better suited for one of the various support
> channels. Including but not limited to the
> debian-u...@lists.debian.org mailinglists, which are even available
> in different languages.
> Some quick answers anyway:
Thanks
I changed it from the user list at the last minute as
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.
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 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
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 (
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
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 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 co
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 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 i
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
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
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
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
gener
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
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 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 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 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 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 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 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 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 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 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 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
1 - 100 of 155 matches
Mail list logo
