Matthias Urlichs writes:
>> Agreed: either it's drop-in compatible or we may as well switch the
>> default to NM and/or systemd-networkd.
>
> Well, here's a heretical thought: why don't we do that anyway, at
> least for new installations?
>
> Somebody could even write a converter. Shouldn't be th
Matthias Urlichs writes:
> On 09.07.24 12:27, Bjørn Mork wrote:
>> Run user scripts on up/down events. That's a huge blank spot in
>> systemd-networkd. And by design, so it's really not fixable.
>
> Well, I've been apt-purging ifupdown for almost a decade by
Lukas Märdian writes:
> But in the end we don't want to bloat our base-installation with
> NetworkManager and systemd-networkd is not fit to cover the desktop/laptop
> usecase. So why not put some glue around it, to make it all feel coherent,
> without limiting anybody in their decision to choose
Gerrit Pape <[EMAIL PROTECTED]> writes:
> On Mon, Nov 06, 2006 at 11:34:14PM +0100, Sz?kelyi Szabolcs wrote:
>> can anyone tell why ftpds do conflict with each other and why httpds do
>> not?
>
> Actually the httpds should conflict too as they install listeners on
> 0.0.0.0:80.
Nope, not IMHO. The
[EMAIL PROTECTED] writes:
> Yet there are also many users, probably those who are not
> professional administrators, that _need_ for everything to work out of the
> box.
> Who should we help more: those who get paid to administer the machines,
> and are probably much more knowledable, or the oc
Tiago Saboga <[EMAIL PROTECTED]> writes:
> I prefer a) over b), but for the sake of completeness, we should point that
> there is third choice:
> c) allow it to work, automagically determining new ports
>
> For this to work, the user would have to choose which server is the "main"
> one. I don't
Clint Adams writes:
> -idl=$(ls /etc/init.d/${service} 2> /dev/null | head -n 1)
> +idl="/etc/init.d/${service}"
> if [ -n "$idl" ] && [ -x $idl ]; then
You might as well remove the -n test if you do this. There's not much
chance of hitting it anymore...
Bjørn
--
T
Tollef Fog Heen writes:
> ]] Roger Leigh
>
> | Having working local networking is important. We wouldn't consider
> | broken IPv4 loopback acceptable, and broken IPv6 loopback is just as
> | bad.
>
> Sure, having it working is important. Is it more important than keeping
> those (often new) use
"Giacomo A. Catenazzi" writes:
> 5) We create a new free database.
>
> I don't think is too difficult, and I think we would have support
> also at high level.
> But it needs a lot of communication works: the term of service of
> IANA and the RIRs (Regional Internet Registry) forbid to spider and
Steve Langasek writes:
> I still can't fathom why someone decided that udev should be responsible for
> translating PCI IDs and USB IDs into text strings. This smells of crazy.
Yes. Any device specific matching should use vid:pid. How about just
disabling the /lib/udev/{pci,usb}-db helpers al
m...@linux.it (Marco d'Itri) writes:
> On Sep 04, Bjørn Mork wrote:
>
>> Yes. Any device specific matching should use vid:pid. How about just
>> disabling the /lib/udev/{pci,usb}-db helpers alltogether to avoid ever
>> getting any users of this info in D
m...@linux.it (Marco d'Itri) writes:
> On Sep 04, Ron Johnson wrote:
>
>> Whatever the cause, it breaks the FHS.
> Since it keeps being repeated, it is time to destroy this argument.
> FHS documents what distributions want to do: of the other relevant
> distributions, representatives from Red Hat
Hendrik Sattler writes:
> Am Freitag 04 September 2009 16:36:52 schrieb Michael Biebl:
>> devkit-disks-part-id and devkit-disks-probe-ata-smart both link against
>> libraries which are (currently) in /usr/lib, i.e.
>> devkit-disks-part-id links against libglib-2.0 (784K)
>> devkit-disks-probe-ata-
m...@linux.it (Marco d'Itri) writes:
> On your part, you could try to understand them instead of attributing to
> me straw man positions.
That's a good advice. Thanks. Please help me understand: What is the
usb-db and/or pci-db use case?
I'm afraid my creative imagination is far too limited to
Josselin Mouette writes:
> Le vendredi 04 septembre 2009 à 19:32 +0200, Hendrik Sattler a écrit :
>> It rather needs to raise the question why simple low-level tools use
>> something
>> like libglib?
>
> I’d rather raise the question why each of our simple low-level tools
> implement its data s
Josselin Mouette writes:
> Le lundi 07 septembre 2009 à 11:48 +0200, Bjørn Mork a écrit :
>> You're not seriously suggesting that DeviceKit-disks usage of g_print
>> instead of printf is actually adding anything useful?
>
> Yeah sure, just look at g_print and not at
Raphael Hertzog writes:
> after several rounds of discussion on -devel, we now have a
> new standard defining meta-information to integrate on patches that we
> distribute/apply in our packages:
> http://dep.debian.net/deps/dep3/
Just a minor comment on the examples: Please either use your own d
Josselin Mouette writes:
> Le lundi 07 septembre 2009 à 20:00 +0200, Giacomo A. Catenazzi a
> écrit :
>> Steve Langasek wrote:
>> > Case 1, please. Either case 2 fails to handle the allocation error, or
>> > glib
>> > is doing its own abort. Neither is acceptable.
>
> Yeah, sure. As if there w
Nicolas François writes:
> When an user is created, useradd creates a /var/mail/$USER mailbox with
> the mode 0660 (owned by $USER:mail).
>
> I heard this causes some issues for dovecot, and a solution could be to
> move to mode 0600.
Where did you hear this?
Exactly what did you hear?
Is this
Ana Guerrero writes:
> If you really want to help, read the mail archive of the debian-python
> mailing list [1] (optionally hang out in the IRC channel), and get
> an idea of what the problem is.
> I also advise to take a look to the archive to people participating
> in this thread who has no
Luk Claes writes:
> This discussion on -devel is quite useless and contra productive for
> everyone involved.
>
> There is currently discussion ongoing about how to move forward, though
> due to the complex nature of the current situation (where also lots of
> FUD etc is on the lists), it is bein
Jarek Kamiński writes:
> Yes. Following code actually works (runs with bindv6only enabled,
> listens on [::]:1234 and accepts connection made to localhost:1234):
I'm sure it works. But I wanted to note that "localhost" is somewhat
ambigious. It may include ::1
ipv6-pppoe-1:~# grep localhos
Steve Langasek <[EMAIL PROTECTED]> writes:
> On Tue, Jul 08, 2008 at 01:47:51PM +0200, Martijn van Oosterhout wrote:
>> On Tue, Jul 8, 2008 at 2:37 AM, Joey Hess <[EMAIL PROTECTED]> wrote:
>> > http://sourceware.org/bugzilla/show_bug.cgi?id=4980
>
>> I just find it wierd that there doesn't appear t
Bastian Blank <[EMAIL PROTECTED]> writes:
> On Mon, Aug 11, 2008 at 08:48:29AM +0200, Petter Reinholdtsen wrote:
>> I really wish there was some organized way for packages to
>> automatically add schemas and settings to the OpenLDAP server
>> configuration, at install time.
>
> ldap is a network ba
"Dmitry E. Oboukhov" <[EMAIL PROTECTED]> writes:
> On 18:42 Wed 13 Aug , Brian May wrote:
>> Dmitry E. Oboukhov wrote:
>>> qemu makes mount the directory /tmp/mount.$$. Attacker creates many
>>> symlinks /tmp/dir.\d+ -> /etc and if qemu
>>> (/usr/sbin/qemu-make-debian-root) starts then /etc goe
maximilian attems <[EMAIL PROTECTED]> writes:
> kernel-img.conf(5) has nothing to do with initramfs-tools.
> there you'll find do_bootloader documented.
I am glad you are referring to this man page. I found myself looking
for it a while ago, surprised to find that it wasn't installed on the
syst
William Pitcock <[EMAIL PROTECTED]> writes:
> If you have both GRUB and LILO installed, there will be problems. That
> is infact, a bug. They should Conflict with each other to ensure that
> only one can be installed at a time, but it is a minor bug at best, as
> any smart user would not have both
maximilian attems <[EMAIL PROTECTED]> writes:
> On Wed, Aug 27, 2008 at 09:07:29AM -0500, William Pitcock wrote:
>>
>> If you have both GRUB and LILO installed, there will be problems. That
>> is infact, a bug. They should Conflict with each other to ensure that
>> only one can be installed at a t
maximilian attems <[EMAIL PROTECTED]> writes:
> kernel-img.conf does not pertain to any package, this is meant to be solved
> postlenny by linux images using debian kernel toolkit [1]
>
> kind regards
>
> --
> maks
>
> [1] http://multibuild.org/documentation/dkt
Sounds good! Thanks for the point
Craig Small <[EMAIL PROTECTED]> writes:
> Package: wnpp
> Severity: wishlist
> Owner: Craig Small <[EMAIL PROTECTED]>
>
> * Package name: gw6c
> Version : 5.1
> Upstream Author : Hexaco
> * URL : http://go6.net/4105/download.asp
> * License : BSD
> Programming
Luca Capello <[EMAIL PROTECTED]> writes:
> [2] http://www.g10-code.de/p-card.html
I assume this was supposed to be
http://www.g10code.de/p-card.html
Bjørn
--
Luser
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Moritz Muehlenhoff <[EMAIL PROTECTED]> writes:
> We've discussed this at the Security Team meeting in Essen and we don't
> have a problem with qmail being included in Lenny.
You are aware of upstream's attitude towards security holes? There are
lots of assumptions like "nobody will ever do ...".
Gerrit Pape <[EMAIL PROTECTED]> writes:
> Hi, I'm quite surprised how the inclusion of qmail and related packages
> into sid is handled, or rather not handled, by the ftpmasters.
I downloaded the netqmail source from http://dbn.smarden.org/sid/ and
looked briefly at it, to see if most of the well
Florian Weimer writes:
> * Emilio Pozuelo Monfort:
>
>> Description : automatic proxy configuration management library
>>
>> libproxy is a lightweight library which makes it easy to develop
>> applications proxy-aware with a simple and stable API.
>
> WPAD is a broken protocol with securit
Fabian Greffrath writes:
> - Sites with domain names like do already exist!
> Do you think they should be accessible by any other proprietary
> operating system, but not Debian? Not really!
Anyone can enter bogus data in the DNS. Neither the existence of such
data nor the failure to detect it
Petter Reinholdtsen writes:
> [Roger Lynn]
>> But apt has been using pipelining for years. Why has this only just
>> become a problem?
>
> It has been a problem in Debian Edu for years. Just recently I
> figured out the cause and a workaround.
And FWIW I have experienced this problem for years t
Pierre Habouzit writes:
> On Wed, May 19, 2010 at 10:42:55AM +0200, Bjørn Mork wrote:
>
>> 2) http proxy servers cannot always process pipelined requests due to
>>the complexity this adds (complexity is always bad for security), and
>
> This is bullshit. It&#
Goswin von Brederlow writes:
> A HTTP/1.1 conforming server or proxy
This is not the real world...
> is free to process pipelined
> requests serially one by one. The only requirement is that it does not
> corrupt the second request by reading all available data into a buffer,
> parsing the fir
Daniel Baumann writes:
> as of current git, you can now use EXTLINUX_UPDATE=false in
> /etc/default/extlinux to prevent having update-extlinux do anything.
That's the single feature I misseded. Thanks.
Although it would be even better if it was possible to include some
fixed part in it, while
Paul Wise writes:
> How many times will this discussion will go round and round in
> circles? I'm getting dizzy.
I believe it will continue until someone finds the end of the circle.
Bjørn
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Tro
Petter Reinholdtsen writes:
> [Petter Reinholdtsen]
>> Are there better ways to do this? Anyone willing to work on it?
>
> One alternative would be to move the information out of the
> discover-data package, and into the Packages file instead, similar to
> how Iceweasel[1] and Moonlight[2] might
Joachim Wiedorn writes:
> After the long silence about the popular bootloader LILO the development
> was started again.
>
> The new Homepage can be found here:
> http://lilo.alioth.debian.org/
>
> For the development of the bootloader I have started an Alioth project
> with Git repository and Mai
"Jesús M. Navarro" writes:
> "so good that *I* will prefer it over others".
The problem with this is that we all(?) already prefer Debian.
In my eyes, there is no question about which distro to choose. I prefer
Debian for so many reasons that I'm not sure I'm able to list them all.
But some o
Russ Allbery writes:
> Having followed the Ubuntu bugs for many of my packages for several years
> now, I think Debian's bug system is considerably more user-friendly than
> Launchpad. It may not be as *pretty*, and it's not as easy to submit a
> bug, but when you submit a bug to Debian, the cha
Andreas Tille writes:
> On Thu, Jul 22, 2010 at 04:05:17PM +0200, Stefano Zacchiroli wrote:
>>So, point 2: are we *advertising* reportbug enough to our users?
>>In particular, I'm thinking about advertising in "push mode" rather
>>then in "pull mode".
>
> No, we obviosely do not. When
Stefano Zacchiroli writes:
> On Thu, Jul 22, 2010 at 06:00:44PM +0200, Bjørn Mork wrote:
>> > No, we obviosely do not. When staffing bothes in the past I regularly
>> > asked people to report their problem and they had no idea how to do
>> > (because they did no
Ron Johnson writes:
> On 07/22/2010 11:42 AM, Bjørn Mork wrote:
> [snip]
>>
>> But this is not a problem you can solve. You cannot avoid requiring
>> some effort from users wanting to report a bug.
>>
>
> For some value of "some effort".
>
> MS
Philipp Kern writes:
> DHCPv4 and DHCPv6 are sufficiently different protocol-wise to warrant two
> different clients. (The v6 people might not want to deal with the cruft
> of DHCPv4 too...)
Absolutely!
Create a new DHCPv6 client, cleanly implementing the protocol without
having to carry all
Russ Allbery writes:
> For reference for others reading this, the postinst of the relevant
> package follows. Note that it adds an unqualified hostname, potentially
> shadowing a system in the local domain, if the user agrees to update
> /etc/hosts. The debconf question is priority: high and de
Josselin Mouette writes:
> On a different, although similar issue, how would a change
> of /etc/inittab in a maintainer script be regarded?
> (I’m considering it for gdm3 in wheezy.)
If I wanted some random package maintainer to mess with my configuration
files, then I would probably just have u
Josselin Mouette writes:
> Le mardi 11 janvier 2011 à 18:27 +0100, Bjørn Mork a écrit :
>> If I wanted some random package maintainer to mess with my configuration
>> files, then I would probably just have used Fedora or whatever.
>
> I am not seeking the opinion of other ra
Michael Biebl writes:
> Completely agreed. The focus of dependency based boot is correctness.
> The old system with static start/stop priorities was a pain to maintain and
> actually had many bugs which were effectively impossible to change, because
> changing the priority of *one* package can le
After discovering two different unrelated packages abusing the pm-utils
hooks, I started wondering if there are any generic guidance wrt such
hooks.
Can any package just provide the hook directories it want without an
explicit policy? And can any package provide hooks in such directories,
even
James Vega writes:
> On Mon, Jan 17, 2011 at 12:43 PM, Bjørn Mork wrote:
>> My claim is that packages like unattended-upgrades and pm-utils are
>> completely unrelated to each other, and that a hook in
>> unattended-upgrades which breaks pm-utils by preventing hibernation
Neil Williams writes:
> On Mon, 17 Jan 2011 18:43:23 +0100
> Bjørn Mork wrote:
>
>> Can any package just provide the hook directories it want without an
>> explicit policy?
>
> A general policy for all hooks sounds like a difficult thing to create
> - it could
Neil Williams writes:
> Different package objectives. cron-apt may be what you are actually
> thinking of. Even then, I wouldn't use cron-apt on a laptop.
Well, I do like security updates to just be there and I don't like to do
sysadmin tasks. So I want some sort of automated package upgrades.
James Vega writes:
> The bug[0] which was the impetus behind adding that script seems sound
> to me. Delaying hibernation to ensure that the system isn't left in an
> unbootable state is a fair trade-off.
>
> [0]: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/191514
Yes, its an ugly bug
Noah Slater writes:
> On Sun, Feb 22, 2009 at 05:18:39PM -0800, Asheesh Laroia wrote:
>> I think that the description explains that the purpose is to find hidden
>> directories on web servers, presumably either your own or other people's.
>
> Why would you need to find directories on your own serv
Josselin Mouette writes:
> Le vendredi 27 février 2009 à 14:33 +0100, Raphael Hertzog a écrit :
>> On Fri, 27 Feb 2009, Joerg Jaspert wrote:
>> > Like the other poster, cli is very confusing. If we have enough
>> > packages (get me a list/matches :) ), im not against a section for it,
>> > but cli
Martín Ferrari writes:
> Problematic tools:
> * mii-tool: it could be dropped and replaced by a pointer to ethtool as
> it's not meant to be used automatically by scripts. On the other hand,
> it's distributed as a stand-alone tool [0] and we could do the same.
A couple of notes:
mii-tool and
Ben Hutchings writes:
> On Mon, Mar 16, 2009 at 01:08:04PM +0100, Bjørn Mork wrote:
>
>> mii-tool may not be meant for scripts, but I for one have used it in
>> the past to force speed/duplex like this:
>>
>> iface eth1 inet static
>> addr
Samuel Thibault writes:
> Giacomo Catenazzi, le Wed 08 Apr 2009 19:47:55 +0200, a écrit :
>> Samuel Thibault wrote:
>> >> I installed grub (and Debian). Trying the Windows hidden partition
>> >> (to install windows), grub stopped working (it was rescue mode, but
>> >> without capability to rescue
Julien Cristau writes:
> On Sun, 2009-04-12 at 14:04 +0200, Michael Meskes wrote:
>> On Mon, Apr 06, 2009 at 09:55:39PM +0200, Michael Biebl wrote:
>> > As (co-)maintainer of pm-utils and hal, I'd prefer if we could work towards
>> > standardizing on one power management stack in Debian (and not i
Julien Cristau writes:
> On Wed, 2009-04-15 at 10:25 +0200, Bjørn Mork wrote:
>> Well, you can always argue that the rest can be fixed. Provide patches
>> etc. But the point is that hal implies a regression for many (most?)
>> users.
>
> please stop the FUD.
Sorr
Josselin Mouette writes:
> Le jeudi 16 avril 2009 à 00:34 +0200, Bjørn Mork a écrit :
>> My list of hal related regressions are
>> a) laptop keys remapped or disappearing (might be caused by the driver -
>>I don't know)
>
> Yes, they are remapped to t
Josselin Mouette writes:
> Le jeudi 16 avril 2009 à 15:06 +0200, Bjørn Mork a écrit :
>> >> a) laptop keys remapped or disappearing (might be caused by the driver -
>> >>I don't know)
>> >
>> > Yes, they are remapped to the standard XF86* name
Josselin Mouette writes:
> Le lundi 20 avril 2009 à 10:26 +0200, Bjørn Mork a écrit :
>> I prefer non-broken defaults. hal defaults are broken. No, the keys are
>> not always mapped to standard XF86* names. They are sometimes mapped
>> into the blue.
>>
>
Josselin Mouette writes:
> If it’s just your decision, why are you bitching on this list?
That's a good question. It was fun for a while. But I think the
spectators are getting a bit bored. I'll stop now. Thanks for your
answers. Believe it or not, but I've learned a lot about hal from this
Matthew Garrett writes:
> powertop makes various recommendations that are only useful in very
> specific circumstances. Disabling polling in hal saves you a small (and
> probably not useful in the real world) amount of power, but is required
> to get to the number of wakeups per second that Arjan
Michael Biebl writes:
> See the hal-disable-polling man page. In short: hardware support for MMC media
> change notification is broken.
Err. You are using the "broken firmware" argument both ways.
You should follow your own advice regarding the drives spinning up:
Implement a blacklist of devi
Mike Hommey writes:
> On Sat, Apr 25, 2009 at 09:56:54AM +0200, Giuseppe Sacco wrote:
>> Il giorno ven, 24/04/2009 alle 22.30 +0200, Mike Hommey ha scritto:
>> [...]
>> > I'm not sure iceweasel uses gnome settings, but uses what gnome exports
>> > in the *_proxy environment variable. Can you check
Henrique de Moraes Holschuh writes:
> On Sun, 26 Apr 2009, Matthew Garrett wrote:
>
>> Hal checks the drive capabilities and shouldn't be polling drives that
>> support async notifications. Is that code not working for you?
>
> It is working fine, thanks for the head's up about it disabling the p
Holger Levsen writes:
> On Montag, 27. April 2009, Noah Slater wrote:
>> * The Debian lists do not have a Reply-To header,
>
> does someone know why?
I don't know, but there are plenty of reasons to choose from. See e.g.
http://www.unicom.com/pw/reply-to-harmful.html
Those not wanting redund
Josselin Mouette writes:
> Mail-Followup-To is:
> A. Useless junk without clear semantics
> B. Violating standards
Which standards would that be?
Bjørn
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@li
Josselin Mouette writes:
> I’m not subscribed to any list which set the Reply-To header. Could you
> at least show some examples of such lists in the free software world?
What's "the free software world"? Is that a separate networking domain,
or is it connected to the Internet?
Anyway, here ar
Brian May writes:
> On 14 November 2014 04:20, Carlos Alberto Lopez Perez
> wrote:
>
>> The last one that I read is that udev is going to stop working on
>> non-systemd systems:
>>
>> http://lists.freedesktop.org/archives/systemd-devel/2014-May/019657.html
>>
>>
> I don't read anything in that po
m...@linux.it (Marco d'Itri) writes:
> On Nov 17, Steve Langasek wrote:
>
>> > This is what many still (retorically) wonder about: we the systemd
>> > maintainers did not reject that change,
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=15;bug=746578
> Please try to be less selective in
Josselin Mouette writes:
> Is this the right time to do it?
Wasn't this just recently discussed? Just replay the thread:
http://lists.debian.org/debian-devel/2011/10/msg00227.html
Bjørn
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Troub
Uoti Urpala writes:
> Machine-specific configuration belongs in /etc. The default behavior of
> the tools doesn't.
Agree. Copying a large set of default policies into /etc just because
they *can* be overridden is not user friendly. And it does not make the
defaults any more configuration eithe
Timo Juhani Lindfors writes:
> Wookey writes:
>> And the USB-stick process is not as simple as it might be because you
>> have to find the HD-media files and then _also_ find an iso image to
>> put on. It's no wonder newbs are still downloading CD/DVD images.
>
> You also need to have root acces
Timo Juhani Lindfors writes:
> Bjørn Mork writes:
>> No, you don't. On a default Debian system you need to be a member of
>> the "floppy" group. From /lib/udev/rules.d/91-permissions.rules :
>
> Yeah but you are not a member of that group by default surely?
Vincent Lefevre writes:
> On 2012-05-30 12:08:29 +0200, Josselin Mouette wrote:
>> Le samedi 26 mai 2012 à 23:02 +0200, Carlos Alberto Lopez Perez a
>> écrit :
>> > With "tmpfs on /tmp" you are breaking many applications that assume that
>> > they have enough space to write on /tmp like the flash
Petter Reinholdtsen writes:
> I've happily been using tmpfs on /tmp/ for probably ten years now, and
> can list some more benefits:
>
> - It allow diskless setups like LTSP to work the same way the default
>installation in Debian work. They use read-only NFS-mounted file
>systems and a
Petter Reinholdtsen writes:
> [Bjørn Mork]
>> I'd like to add another one:
>>
>> - a tmpfs is always easy to grow without requiring any special
>> preparations. Just add more swap. The swap could be on different
>> disks, and could even be files hosted
Serge writes:
> 2012/6/10 Adam Borowski wrote:
>
>>> Some people asked for a thread summary. So here it is.
>> Seriously, can't you even read what's written to you?
>
> Yes, I know it was a biased summary.
I think you might start to piss off a few people now...
Look at what you are quoting above
Aneurin Price writes:
> (Note that we are talking about applications which fail gracefully
> when confronted with ENOSPC,
Are we? What's the problem then?
> but which are likely to do so more often when the size of /tmp is
> restricted.)
Yes, but the tmpfs correlation is weak. There is absol
Aneurin Price writes:
> In anything resembling a 'normal' system (ie. the kind where one might
> be using the defaults) I would say that the tmpfs correlation is so
> strong as to be very nearly 1:1, and this seems like the crux of the
> matter; that is after all the reason that these application
Serge writes:
> Since tmpfs+swap is mostly slower than regular filesystem
And the world is flat.
Bjørn
--
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/874nqfn0af..
Jean-Christophe Dubacq writes:
> On 11/07/2012 11:12, Andrei POPESCU wrote:
>> On Mi, 11 iul 12, 10:55:16, Jonas Smedegaard wrote:
>>>
>>> The feature of _allowing a subset of packages to be removed that was
>>> _ensured_ to be installed: Impossible without defeating the feature of
>>> _ensuring
Christoph Anton Mitterer writes:
> On Sun, 2012-08-19 at 19:41 +0200, Marco d'Itri wrote:
>> NM, as a design goal, is not supposed to be able to manage every
>> possible configuration.
> Well but then it shouldn't be kind of a default package.
No it shouldn't. And it isn't either. gnome-core i
Stephan Seitz writes:
> On Mon, Aug 20, 2012 at 01:08:53PM +0200, Bjørn Mork wrote:
>>Never mind wireless lan where you've got a well defined kernel API. Try
>>to configure a modern 3G/LTE modem using ifupdown, and you will see the
>
> Is this something different from a
Serge writes:
> 2012/8/30 Wouter Verhelst wrote:
>
>>> How do you suppose it's possible to undo arbitrary network
>>> configuration done by arbitrary set of tools when there's no central
>>> place to hold such information (and can't possibly be)?
>>
>> Actually, the kernel holds that information.
Josselin Mouette writes:
> Le mardi 28 mai 2013 à 10:34 +0100, Jonathan Dowland a écrit :
>> There is an impedence mismatch between packages which consider an MTA and the
>> sendmail interface to be standard and those desktop components that make no
>> such assumption. If we are going to keep ens
Josselin Mouette writes:
> Le mardi 28 mai 2013 à 13:07 +0200, Bjørn Mork a écrit :
>> The local MTA serves as a common configuration for the external SMTP
>> server, with a well known interface supported by every single package
>> which wants to send mail.
>
> Whi
Russ Allbery writes:
> Bjørn Mork writes:
>
>> The local MTA serves as a common configuration for the external SMTP
>> server, with a well known interface supported by every single package
>> which wants to send mail.
>
> And which requires storing passwords or ot
Ben Hutchings writes:
> On Wed, May 29, 2013 at 09:06:59PM +0200, Adam Borowski wrote:
>> On Wed, May 29, 2013 at 05:11:35PM +0200, Josselin Mouette wrote:
>> > Le mercredi 29 mai 2013 à 16:31 +0200, Javier Fernandez-Sanguino a
>> > écrit :
>> > > Take for example, smartmoontools [1]. Currently,
Marc Haber writes:
> On Thu, 30 May 2013 06:46:46 -0400, Scott Kitterman
> wrote:
>>Even if they are using a system
>>that allows them to go back and review their notification history when they
>>return to their system,
>
> It just occurred to me that you are describing a mail client.
Let's ad
Jean-Christophe Dubacq writes:
> And in my experience, email tends to be much more fragile than dbus.
The warm fuzzy feeling you get when you don't know there is a
problem...
> How many times have I suddenly looked
> at the queue of a computer that has been mis-configured and that
> accumulate
Michael Stapelberg writes:
> since some people might not read planet debian, here is a link to my
> first blog post in a series of posts dealing with the results of the
> Debian systemd survey:
>
> http://people.debian.org/~stapelberg/2013/06/09/systemd-bloat.html
I was hoping you would cover my
Michael Biebl writes:
> The persistent network interface naming rules are already skipped if
> udev is run within a virtual machine.
Which made me look closer at
/lib/udev/rules.d/75-persistent-net-generator.rules
I find it a bit strange that it has lots of logic involving different
OUIs, but
1 - 100 of 195 matches
Mail list logo
