Re: serious bug. Evolution and Microsoft mentality.

[tpo2]

Zitiere Erik Steffl [EMAIL PROTECTED]:


[1935 lines uselessly quoted]
 
 IMO the good solution for this kind of problems is to use IMAP.
 don't trust MUAs to work with files.

IMO IMAP is still a PITA, AFAIK the only well and out of the box interoperating
combination of MUA and IMAPd is pine together with uw-imapd which is about as
configurable as your sunglasses. With other Linux combinations you'll have to
go fiddling with Prefix|View = INBOX. | INBOX* | INBOX.% | INBOX etc.

IMO nothing for newbies.

*Tomas Pospisek

Re: reopening ECN bugreport/netbase

[tpo2]

Thanks for caring Anthony!

Zitiere Anthony Towns aj@azure.humbug.org.au:

 I'm not sure what you mean by idealism but surely it's obvious the
 solution that's closest to ideal for the most users should be chosen as
 the default. We've currently had what options?
 
  1) Disable ECN in the kernel, and let people who want it recompile
 the kernel by hand. Pros: doesn't hurt anyone, follows the upstream
 kernel defaults.  Cons: makes it hard for people to enable, which
 in the long term damages the Internet's resiliance to DoS attacks.
 
  2) Leave ECN in the kernel, but disable it externally by default.
 Pros:
doesn't hurt anyone, makes it easy to change. Cons: requires
 kludging
around in other packages (boot-floppies and procps/netbase)

Cons for procps: solving it here is a techincally bad choice, since
it would require procps to decide to assign the flag based on available kernel 
options. Which is doable for this specific problem but is not a
general solution for similar problems.

Pros netbase: The message ECN disabled: use /etc/network/options to enable
keeps reminding the user which rises the probability that s/he will enable it 
later and so serve the purpose of ECN in the first place.

  3) Leave ECN in the kernel, enabled by default. Pros: easy to setup,
 easy
to change after the fact. Cons: neophytes can easily be confused
 when
random sites start not working unpredictably from Debian machines
 but work fine elsewhere.

Cons: if upstream doesn't accept the changed default and include it, there
forever be a fork between Debian an the main kernel. Changing the default
upstream will cause a lot of trouble there which makes it not very probable.
IMO this would be the cleanest solution though.

 Another option, which would require a minor patch to the kernel, would
 be
to have ECN default to disabled even when compiled into the kernel (and
 thus require an explit 'echo 1 /proc/sys/net/ipv4/tcp_ecn' to enable).
 This'd be analagous to the current behaviour with IP forwarding.
 
 There might be other options too.

Both 1) and 3) would require action from the kernel-image maintainer, which
requires someone else than me talking to him since he's either not seeing
ECN as his problem at all:

 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=110862msg=8

or just ignoring my reports:

 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=110862msg=14

*t

Re: sysctl should disable ECN by default

[tpo2]

Well all of this has been said on this thread here allready, but
I'll repeat it never the less to get the facts straight.

Zitiere Dominik Kubla [EMAIL PROTECTED]:

 On Wed, Sep 05, 2001 at 05:30:12PM +0200, T.Pospisek's MailLists wrote:

 But the whole discussion here is folly. The whole thing has been
 discussed
on linux-kernel by people far more knowlegable in this things
 than the
average debian developer.  I think we should follow the
 conclusions
from that discussions: enable ECN by default and every
 non-compliant
device be dammned.

However you, or whoever on the kernel lists might argue, the default in
Linus' kernel sources is off! Please check it yourself.

 Mind you that we are only talking about firewalls here (and all of the
 can be fixed by firmware upgrades, or at least they should).

Fact is some aren't.

 Ordinary
routers have no business altering packets passing through and
 ordinary
hosts have to ignore reserved bits they don't know about.
 Routers
doing NAT are to be treated as firewalls.  If they are broken:
 replace
them.  They will have more bugs that this one anyway.

You are wellcome to be without a fault. Unfortunately a lot of HW/SW isn't.
And often enough it's not up to the user to replace it. He just has to live 
with it.

I think Craig Sanders and Anthony Towns said it best:

Craig:

 the fact is that there is no possibility of harm if ECN is disabled
 in the kernel, while there IS possibility of harm if it is enabled.
 therefore it should be disabled by default.

Anthony:

 I'm not sure what you mean by idealism but surely it's obvious the
 solution that's closest to ideal for the most users should be chosen as
 the default.

*t