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:
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 they were
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 menu
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 a
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
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 reduce
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
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
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 I
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 the
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.
olivier sallou olivier.sal...@gmail.com 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
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
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 james...@debian.org 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
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
anything to
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 (please
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.
Well
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 do
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
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 with
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 Common
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 come
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
workaround.
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 new
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 security
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
eliminate
* 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
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
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
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 old
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
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
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 as
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
left
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 issues are already catered
* 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 from
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.
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.
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! :)
Though that's
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 want
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-truth/half-omission
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
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
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 of
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 the
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
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 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 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 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 like
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 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 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 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 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 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 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 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 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 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
1 - 100 of 155 matches
Mail list logo
