RE: etch upgrade problem
Andrei Popescu <mailto:[EMAIL PROTECTED]> wrote on Tuesday, April 10, 2007 10:35 AM -0500: > "Seth Goodman" <[EMAIL PROTECTED]> wrote: > > > In another thread, someone suggested "dpkg-reconfigure udev" for > > other hardware detection problems, so I tried it. That refuses to > > run because it wants a more recent kernel. > > Missed this the first time. What kernel are you running and what > version of udev? If you are still running the sarge kernel then you > should upgrade (but read the release notes first). Installing initrd-tools and then upgrading the kernel to 2.6.18 fixed the mouse and vga detection problems with X, so gnome runs. I may decide to do a clean install of etch when I find the time, but at least I have a desktop. Reading release notes is always an excellent idea, so we could safely label this problem as PEBKAC. OTOH, my setup was within the envelope for Debian stable, so the same will probably happen to other casual users. I also suspect it's avoidable. The setup that led to this upgrade problem was: - Debian stable installed as desktop system plus server - all package management done through Synaptic - repositories pointed to stable, not Sarge - Gnome screen saver active When the Etch release appeared, Synaptic offered to upgrade all the packages just as I expected after seeing the release announcement on the list. What I also expected was that Synaptic would either upgrade/install/remove packages in an appropriate order, or tell me that it couldn't. After all, this was a transition from pure stable to pure stable, nothing out of the ordinary. Instead, it apparently removed some of the Sarge hardware detection packages and installed udev without requiring a kernel upgrade. It also replaced X while X was running, causing the (standard Gnome) screensaver to no longer recognize passwords. I am curious whether some debconf action, or dependencies in the deb files, could have warned the user? -- Seth Goodman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: etch upgrade problem
Andrei Popescu <mailto:[EMAIL PROTECTED]> wrote on Tuesday, April 10, 2007 10:35 AM -0500: > "Seth Goodman" <[EMAIL PROTECTED]> wrote: > > > In another thread, someone suggested "dpkg-reconfigure udev" for > > other hardware detection problems, so I tried it. That refuses to > > run because it wants a more recent kernel. > > Missed this the first time. What kernel are you running and what > version of udev? If you are still running the sarge kernel then you > should upgrade (but read the release notes first). It's the Sarge kernel, 2.6.8.3-686, specifically 2.6.8-16sarge6. I can understand that some people may wish to upgrade to etch without replacing their kernel, but I'm surprised that synaptic didn't recommend this as part of the normal upgrade. OTOH, it's possible that it did, but kernel replacement failed as a consequence of my killing the screensaver process that was blocking completion of the upgrade. If so, the primary failure in all of this, in addition to my failing to read the release notes first, may be something in the Xorg transition that resulted in the screensaver no longer accepting the password. Since others have reported successful upgrades to etch with X running, that may be the key. I'm pretty sure that everything on this system was from Sarge repositories. -- Seth Goodman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: etch upgrade problem
Andrei Popescu wrote on Tuesday, April 10, 2007 9:05 AM -0500: > Are you using gpm? IIRC the xorg.conf must be setup differently if you > use gpm. gpm package is not installed. -- Seth Goodman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: etch upgrade problem
Andrei Popescu <mailto:[EMAIL PROTECTED]> wrote on Tuesday, April 10, 2007 2:54 AM -0500: > "Seth Goodman" <[EMAIL PROTECTED]> wrote: > > > > > Fatal server error: > > > > failed to initialize core devices > > > ^^^ > > > X cannot find your mouse. Try another device instead of > > > /dev/psaux. I have /dev/input/mice > > > > Same result. > > Have a look for errors in dmesg. I have this: > > ~# dmesg | grep mice > mice: PS/2 mouse device common for all mice No mouse errors in dmesg. In fact, here is the mouse detection line: input: ImPS/2 Generic Wheel Mouse on isa0060/serio1 The mouse is in fact an intellimouse PS/2. The terminal interface can use the mouse (aptitude, for example) but X doesn't find it, even though xserver-xorg-input-mouse is installed. X is also unable to install the "savage" module for my vga card, even though the terminal interface can use the card and xserver-xorg-video-savage is installed. My apt sources list points to stable, not etch (which is how I got here through Synaptic). That shouldn't be an issue, right? > P.S. I have a feeling this is rather related to udev, modules, ... Did > you try using a different mouse? No, I haven't, it's the only non-USB mouse I have left. This is the same PS/2 mouse that Sarge detected properly on this same hardware. In fact, all the hardware is the same as for my last Sarge install. In another thread, someone suggested "dpkg-reconfigure udev" for other hardware detection problems, so I tried it. That refuses to run because it wants a more recent kernel. -- Seth Goodman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: etch upgrade problem
Andrei Popescu wrote on Monday, April 09, 2007 5:28 PM -0500:
> "Seth Goodman" <[EMAIL PROTECTED]> wrote:
>
> > packages, /usr/X11R6/bin contains only a lib directory with a few
> ^
> I guess you mean /usr/X11R6/
Yes, sorry. /usr/X11R6/bin is a symlink to /usr/bin
>
> > Section "InputDevice"
> > Identifier "Configured Mouse"
> > Driver "mouse"
> > Option "CorePointer"
> > Option "Device""/dev/psaux"
> > Option "Protocol" "PS/2"
> > Option "Emulate3Buttons" "true"
> > EndSection
>
> I think your problem is in this section, see below.
>
> > (EE) xf86OpenSerial: Cannot open device /dev/psaux
> > No such device.
> > (EE) Configured Mouse: cannot open input device
> > (EE) PreInit failed for input device "Configured Mouse" (II)
> > UnloadModule: "mouse" (WW) No core pointer registered
> > (II) XINPUT: Adding extended input device "Generic Keyboard" (type:
> > KEYBOARD) xkb_keycodes { include
> > "xfree86+aliases(qwerty)" }; xkb_types{ include
> > "complete" }; xkb_compatibility{ include "complete" };
> > xkb_symbols { include "pc(pc105)+us" };
> > xkb_geometry { include "pc(pc104)" };
> > No core pointer
> >
> > Fatal server error:
> > failed to initialize core devices
> ^^^
> X cannot find your mouse. Try another device instead of /dev/psaux. I
> have /dev/input/mice
Same result.
--
Seth Goodman
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: etch upgrade problem
Matt Richardson wrote on Monday, April 09, 2007 4:39 PM -0500: > I had the same problem when I upgraded sarge to etch some time ago. > The solution was to add psmouse to /etc/modules. Check out lsmod and > see if it's listed already, but I'd guess not. cray4:~# lsmod Module Size Used by <...> psmouse20360 0 <...> cray4:~# cat /etc/modules <...> ide-cd ide-disk ide-generic psmouse -- Seth Goodman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: etch upgrade problem
) IX[B]
[19] -1 0 0xfe00 - 0xfe0f (0x10) IX[B]
[20] -1 0 0xff00 - 0xff1f (0x20) IX[B]
[21] -1 0 0xfff0 - 0x (0x10) IX[B]
[22] 0 0 0x03b0 - 0x03bb (0xc) IS[B](OprU)
[23] 0 0 0x03c0 - 0x03df (0x20) IS[B](OprU)
(II) Loading sub module "int10"
(II) LoadModule: "int10"
(II) Reloading /usr/lib/xorg/modules/libint10.so
(II) SAVAGE(0): initializing int10
(II) SAVAGE(0): Primary V_BIOS segment is: 0xc000
(II) SAVAGE(0): VESA BIOS detected
(II) SAVAGE(0): VESA VBE Version 2.0
(II) SAVAGE(0): VESA VBE Total Mem: 16384 kB
(II) SAVAGE(0): VESA VBE OEM: S3 Incorporated. Savage4
(II) SAVAGE(0): VESA VBE OEM Software Rev: 1.1
(II) SAVAGE(0): VESA VBE OEM Vendor: S3 Incorporated.
(II) SAVAGE(0): VESA VBE OEM Product: Savage4
(II) SAVAGE(0): VESA VBE OEM Product Rev: Rev B
(==) SAVAGE(0): Write-combining range (0xf000,0x800)
(II) SAVAGE(0): 9348 kB of Videoram needed for 3D; 16384 kB of Videoram
available
(II) SAVAGE(0): Sufficient Videoram available for 3D
(II) SAVAGE(0): [drm] bpp: 32 depth: 24
(II) SAVAGE(0): [drm] Sarea 2200+284: 2484
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is -1, (No such device or address)
drmOpenDevice: open result is -1, (No such device or address)
drmOpenDevice: Open failed
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is -1, (No such device or address)
drmOpenDevice: open result is -1, (No such device or address)
drmOpenDevice: Open failed
[drm] failed to load kernel module "savage"
(II) SAVAGE(0): [drm] drmOpen failed
(EE) SAVAGE(0): [drm] DRIScreenInit failed. Disabling DRI.
(EE) SAVAGE(0): DRI isn't enabled
(--) SAVAGE(0): Chose mode 118 at 60Hz.
(II) SAVAGE(0): Using 1280 lines for offscreen memory.
(II) SAVAGE(0): Using XFree86 Acceleration Architecture (XAA)
Screen to screen bit blits
Solid filled rectangles
8x8 mono pattern filled rectangles
Indirect CPU to Screen color expansion
Solid Lines
Image Writes
Offscreen Pixmaps
Setting up tile and stipple cache:
32 128x128 slots
12 256x256 slots
(==) SAVAGE(0): Backing store disabled
(**) Option "dpms"
(**) SAVAGE(0): DPMS enabled
(WW) SAVAGE(0): Direct rendering disabled
(WW) SAVAGE(0): Option "UseFBDev" is not used
(==) RandR enabled
(II) Initializing built-in extension MIT-SHM
(II) Initializing built-in extension XInputExtension
(II) Initializing built-in extension XTEST
(II) Initializing built-in extension XKEYBOARD
(II) Initializing built-in extension XC-APPGROUP
(II) Initializing built-in extension SECURITY
(II) Initializing built-in extension XINERAMA
(II) Initializing built-in extension XFIXES
(II) Initializing built-in extension XFree86-Bigfont
(II) Initializing built-in extension RENDER
(II) Initializing built-in extension RANDR
(II) Initializing built-in extension COMPOSITE
(II) Initializing built-in extension DAMAGE
(WW) SAVAGE(0): Direct rendering disabled
(WW) SAVAGE(0): Option "UseFBDev" is not used
(==) RandR enabled
(II) Initializing built-in extension MIT-SHM
(II) Initializing built-in extension XInputExtension
(II) Initializing built-in extension XTEST
(II) Initializing built-in extension XKEYBOARD
(II) Initializing built-in extension XC-APPGROUP
(II) Initializing built-in extension SECURITY
(II) Initializing built-in extension XINERAMA
(II) Initializing built-in extension XFIXES
(II) Initializing built-in extension XFree86-Bigfont
(II) Initializing built-in extension RENDER
(II) Initializing built-in extension RANDR
(II) Initializing built-in extension COMPOSITE
(II) Initializing built-in extension DAMAGE
(II) Initializing built-in extension XEVIE
(EE) AIGLX: Screen 0 is not DRI capable
(II) Loading local sub module "GLcore"
(II) LoadModule: "GLcore"
(II) Loading /usr/lib/xorg/modules/extensions/libGLcore.so
(II) Module GLcore: vendor="X.Org Foundation"
compiled for 7.1.1, module version = 1.0.0
ABI class: X.Org Server Extension, version 0.3
(II) GLX: Initialized MESA-PROXY GL provider for screen 0
(**) Option "CoreKeyboard"
(**) Generic Keyboard: Core Keyboard
(**) Option "Protocol" "standard"
(**) Generic Keyboard: Protocol: standard
(**) Option "AutoRepeat" "500 30"
(**) Option "XkbRules" "xorg"
(**) Generic Keyboard: XkbRules: "xorg"
(**) Option "XkbModel" "pc104"
(**) Generic Keyboard: XkbModel: "pc104"
(**) Option "XkbLayout" "us"
(**) Generic Keyboard: XkbLayout: "us"
(**) Option "CustomKeycodes" "off"
(**) Generic Keyboard: CustomKeycodes disabled
(**) Option "Protocol" "PS/2"
(**) Configured Mouse: Device: "/dev/psaux"
(**) Configured Mouse: Protocol: "PS/2"
(**) Option "CorePointer"
(**) Configured Mouse: Core Pointer
(**) Option "Device" "/dev/psaux"
(EE) xf86OpenSerial: Cannot open device /dev/psaux
No such device.
(EE) Configured Mouse: cannot open input device
(EE) PreInit failed for input device "Configured Mouse"
(II) UnloadModule: "mouse"
(WW) No core pointer registered
(II) XINPUT: Adding extended input device "Generic Keyboard" (type:
KEYBOARD)
xkb_keycodes { include "xfree86+aliases(qwerty)" };
xkb_types{ include "complete" };
xkb_compatibility{ include "complete" };
xkb_symbols { include "pc(pc105)+us" };
xkb_geometry { include "pc(pc104)" };
No core pointer
Fatal server error:
failed to initialize core devices
--
Seth Goodman
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: etch upgrade problem (SOLVED)
gianca wrote on Monday, April 09, 2007 10:04 AM -0500:
> Have you tried to kill xscreensaver after remotely loggin in?
Florian Kulzer wrote on Monday, April 09, 2007 10:41 AM -0500:
> You can try to kill the screen saver and/or the screen lock.
> However, if I kill the screen lock process on my KDE system then the
> whole X session is terminated; I assume this is a security measure.
> Therefore you should only try this if you are sure that synaptic has
> finished whatever it was doing, to avoid bringing your system in an
> even more inconsistent state.
Leaving things in a partly upgraded and inconsistent state was what I
was afraid of, and Synaptic was definitely not done. However, I saw
gianca's response before yours so I logged in (as root), killed the
screensaver process and fortunately it worked :) I don't know if the
difference was due to gnome vs. kde or killing the screensaver process
as root, but I'm glad it worked. Thanks for the help to both gianca and
Florian. I'll check out the screensaver after rebooting at the end of
the upgrade to check see if it works properly.
Now on to the PERL locale variable warnings. These warnings are all
similar to:
perl: warning: Setting locale failed.
perl: warning: please check that your locale settings:
LANGUAGE = "en_US:en_GB:en",
LC_ALL = (unset),
LANG = "en_US"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
These appear to be generally harmless, but it might be a good time to
fix the locale so this doesn't continue to happen. One solution I read
about was "dpkg-reconfigure locales", but I wanted to ask here before I
go off and break things further :) As I recall, these locale errors
also occurred during the Sarge install long ago, so it is more likely a
Sarge problem than an Etch problem.
--
Seth Goodman
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
etch upgrade problem
I've started an upgrade from Sarge to Etch through the Synaptic Package manager under Gnome. The package repositories all look for stable. I selected the "normal" level of questions from the terminal interface. It was going well, but now XScreenSaver activated and it does not accept my password, so I can't get back to the ongoing update. Running Putty from a nearby windows box does let me log in as that user, so PAM still works. Directly logging in as root remotely (to my surprise, SSH allowed this) and running "who" does show the user running Synaptic, but how do I get back to the running instance of Synaptic? I'm not sure what caused the problem, but I'm thinking of either the change in graphics environment or my choosing to select the keyboard rather than telling it not to touch the previous selection. If I select "new login" at the screensaver prompt, that also fails trying to load various font packages, so I can't determine if the keyboard map is proper. If I hit the caps lock key, the screensaver does suggest I check for caps lock, so the keyboard works at least a little. Some additional info. Before the screensaver came on, I did notice a long series of warnings concerning what looked like a failure to set the three locale settings for PERL. These same warnings repeated for quite a few packages. I think my settings were both US-English and UK-English for language, locale_all unset and I forget the third variable. It's all on the terminal display behind the screensaver :) TIA. -- Seth Goodman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: GPG and Signing
John L Fjellstad wrote on Thursday, April 05, 2007 10:43 AM -0500: > "Seth Goodman" <[EMAIL PROTECTED]> writes: > > > Instead, they built > > native S/MIME support into their MUA's, built a certificate store > > into their operating system and bought VeriSign. > > Couple of points. There are lots of stuff MS does that don't make > them money. Also, I don't believe they own VeriSign. Like most other companies, MS certainly does things that don't earn a profit. Also like other companies, they generally don't support initiatives that get in the way of other plans. SSL created a market for trusted certificates and CA's. More importantly, it enabled casual web commerce, which was very important to the MS vision of a web supported by advertising and sales of products. Web commerce was much more likely to succeed with a small number of universally trusted CA's, whose identities are distributed with the OS, than with the ad hoc trust networks of individual end users. S/MIME created a second opportunity to earn profits by issuing and serving certificates for email. PGP end users asked their associates to assure the association between their identity and their public keys and published signed keys on free public servers, so there was little profit potential. The two protocols also had different audiences. S/MIME addressed the needs of institutions that would gladly pay for certificates if end users would trust them, while PGP was for human rights workers that needed secure encryption but had no money, or technical end users that favored it for personal/political reasons. One need not invoke any bad intentions to see why S/MIME was a rational choice by MS. On the ownership of VeriSign, MS and VeriSign have collaborated closely, but MS does not appear to own them. I don't recall where I got that idea and I apologize for the error. -- Seth Goodman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: GPG and Signing
John L Fjellstad wrote on Tuesday, April 03, 2007 4:58 PM -0500: > The reason you and people who use OE see it as an attachment is > because MS is unable to implement an 11 years old standard. > This page (http://www.imc.org/smime-pgpmime.html) has a discussion > about the different standards (PGP/MIME and S/MIME) and links to the > different RFCs. S/MIME was intended to work with a certification authority (CA) model based on a small number of universally trusted root CA's, while PGP assumed a distributed web of trust model based on personal relationships between individual users. There's no technical reason a CA can't sign a PGP key, but this was not the intended mode of use. I suggest the problem wasn't MS's inability to implement PGP (it's no harder than S/MIME), but more likely they couldn't see a way to make money from it. Instead, they built native S/MIME support into their MUA's, built a certificate store into their operating system and bought VeriSign. -- Seth Goodman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: GPG and Signing
Michael Pobega wrote on Sunday, April 01, 2007 7:32 PM -0500: > On Sun, Apr 01, 2007 at 07:09:55PM -0500, John Hasler wrote: > > Michael Pobega writes: > > > Is it a bad practice to verify keyrings of people on the mailing > > > list, or is it better to wait until I meet up with some of them > > > at say Debconf or something similar? > > > > Depends on what you mean by "verify". There is nothing wrong with > > downloading their public keys and using them to verify that all the > > messages purporting to come from them are indeed signed with the > > same key and so probably did come from the same person. However, > > you should not sign someone's key unless you have met them, > > interviewed them, and examined and verified their credentials. > > > > What exactly is signing a key, and how does it work? > > I'd Google it...but I wouldn't know where to start. It's a long story, but here's an attempt to make it short ... Public key cryptography has two keys: one public and one private. They are created as a pair and work together. The fact that you can verify a signature against a public key says that the person who signed the message had the private key corresponding to the public key. It says nothing about the identity of the person who created the signature. Public key signatures are more like notary stamps or seals than hand signatures. It says only that the person who signed the file possessed the seal. To help associate a public key with a personal identity, you have to meet someone in person, check an identity document to match a picture to their face. The person them gives you a piece of paper with a "fingerprint" of their public key. You can go home and affix your digital signature to their public key certifying that you are satisfied they are who they claim. Your signature gets added to their public key on the keyserver, so anyone who trusts you can have some trust that this key belongs to the person who claims it. This is how keys inherit trust. The more signatures on your public key, the more likely it is that a random third party knows either someone who signed your key, or knows someone who knows someone who signed your key, etc. As others have pointed out, this is not a guarantee of identity, but it is good enough for most purposes. -- Seth Goodman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: [ML ISSUE] reply-to field ?
Matus UHLAR - fantomas wrote on Saturday, March 31, 2007 6:03 AM -0500: > On 30.03.07 16:33, Seth Goodman wrote: > > That's a large enough hurdle that I think it safe to say the horse > > has left the barn on this one a long time ago. Continuing to insist > > that things _should_ have been different, long past the point where > > that is feasible, only makes us look foolish. In that, we have been > > successful. > > This thread started with complaining about non-existent Reply-To: > headers set by the list. Some people, including me, say that there are > much better ways to solve the mailing list reply problem. Maybe you > should read this thread again. I just did and I don't think I've misinterpreted it. The OP complained about the fact that when reading the d-u list in gmail, as in most other web mail interfaces and MUA's that don't have a reply-to-list function, the reply goes to the original author rather than the list. The suggestions made to the OP were to POP his mail and use an MUA that has reply-to-list, use IMAP and change to an MUA that has reply-to-list, or complain to gmail to get them to do it the debian way. The OP didn't find those suggestions helpful for the same reasons that most other people don't. To summarize them: 1) most people who ask this question are not asking about how to best set up a personal email system on their own server; they only care to read and respond to d-u list traffic, *in addition* to the lists they are currently reading; changing MUA's is a lot of work just to properly read one list; 2) most people are happy with their current MUA or web mail interface, even if people at d-u don't like their choices; since d-u is usually the only list they have encountered that works this way, it is a completely reasonable question to ask, and they don't deserve a public berating for asking; 3) many people find free web mail accounts very convenient, especially for non-critical mail like lists; I don't happen to be one of them, but I recognize the popularity of web mail and don't care to ignore that audience; 4) asking people to complain to gmail/yahoo/msn to implement reply-to-list functionality is an attempt to get them to take on somebody else's technical agenda, and that doesn't work; even if a couple of them did complain, no one is going to change for a few users from a few lists; 5) IMAP is not commonly available as a free service; it takes a fair amount of effort to set up yourself, and not all MUA's support it well; 6) others here pointed out that the d-u community sets its own rules: you either accept them or leave, and likened it to a private yacht club; if that's what d-u is about, then we're in trouble; my understanding was that this is a open community, not a private club full of snobs; we should not treat newcomers that way (or anyone else, for that matter); There's nothing wrong with offering POP + new MUA, IMAP + new MUA or even complain to gmail as alternatives. The problem is believing that a fourth possibility, that d-u operates its lists like the rest of the world, is off limits to discussion. -- Seth Goodman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: [ML ISSUE] reply-to field ?
Ron Johnson wrote on Friday, March 30, 2007 5:50 PM -0500: > And the counter argument would be that not-munging-Reply-To has > always been popular amongst people who know what they are doing. Most people who know what they're doing don't insist that the rest of the world changes its behavior on something that is not important. Besides, you rejected popularity as an argument. -- Seth Goodman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: [ML ISSUE] reply-to field ?
Ron Johnson wrote on Friday, March 30, 2007 4:42 PM -0500: > On 03/30/07 16:33, Seth Goodman wrote: > > That's a large enough hurdle that I think it safe to say the horse > > has left the barn on this one a long time ago. Continuing to insist > > that things _should_ have been different, long past the point where > > that is feasible, only makes us look foolish. In that, we have been > > successful. > > By very similar reasoning, we should all dump Linux and go with the > OS that has 95% usage. Not at all. Unix predated Windows and has had a large following all along. This is different from the preferred usage of mailing list trace headers, which only a small number of implementations ever took seriously. -- Seth Goodman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: [ML ISSUE] reply-to field ?
Matus UHLAR - fantomas wrote on Friday, March 30, 2007 3:31 PM -0500: > The whole fact that "majority" of other mailing lists and their users > does not know about this does not mean it's useless. You mean it _could_ be useful if most others went along, which they haven't. There are a lot of things about normal SMTP practice that violate recent RFC's and I personally don't like. For something that doesn't affect mail transport, but is a matter of how MUA's interpret trace headers, most people feel they have bigger fish to fry. To fix this problem, you need to convince not only the makers of numerous MTA's to change, but the maintainers of mailing list packages and a large number of mailing list administrators. That's a large enough hurdle that I think it safe to say the horse has left the barn on this one a long time ago. Continuing to insist that things _should_ have been different, long past the point where that is feasible, only makes us look foolish. In that, we have been successful. -- Seth Goodman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: Debian Exim SPF howto?
Mihamina (R12y) Rakotomandimby <> wrote on Friday, March 30, 2007 2:21 AM -0500: > Hi, > Would you know any SPF+Debian+Exim tutorial? Exim has native support for SPF starting with version 4.52, but the Debian version has removed it. I believe that was based on a library that was written before the current experimental RFC4408 was submitted, so I don't know its current state of compliance. There are two reference implementations of SPF that are compliant with RFC4408, both on http://www.openspf.org/Implementations. One is Python, the other is PERL. I hear that patches for several MTA's based on these implementations are in the works. -- Seth Goodman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: [ML ISSUE] reply-to field ?
Joe Hart wrote on Friday, March 30, 2007 11:53 AM -0500: > All you are doing is rehashing an argument that has taken place over > and over. You don't like the list, then unsubscribe. Simple. The OP could have presented his request differently, but I don't think a binary answer in the spirit of "love it or leave it" is particularly helpful. The method of handling Reply-To: in this mailing list is in the minority, and even if people believe it to be better, that puts the burden of explanation on us. Having the question come up over and over again, followed by a generally unsuccessful attempt to convince the questioner that everyone else does it wrong, is the price of doing things this way. -- Seth Goodman
RE: [ML ISSUE] reply-to field ?
Ron Johnson wrote on Friday, March 30, 2007 9:06 AM -0500: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 03/30/07 08:32, [EMAIL PROTECTED] wrote: > > I am forwarding previous answers and adding that I do not want > > to pop these mails since I suscribed lots of ML, not only debian > > ones, and it is more convenient for me to read&write from gmail > > than poping 3 times (work - home - laptop) thousands of mails. > > Complain to Google that their MUA is lacking an important feature. It's only important to the Debian mailing lists and a small number of others. It's not important to the majority of other mailing lists, and that's probably why Google and many others don't bother supporting that function. -- Seth Goodman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: Woohooo! Dell + Linux
Paul Walsh wrote on Friday, March 30, 2007 2:23 AM -0600: > Seth Goodman wrote: > > > Most people could not complete a Linux install without a phone call > > to tech support. I suspect that's one part of the reason there are > > so few no-OS boxes. When the install doesn't turn out right, their > > first call is to the people who sold them the hardware, even though > > that's the least likely place to have a problem. Technically > > sophisticated users do not tend to do this, but that's a pretty > > small market. > > > > But surely the people most likely to buy no-OS boxes are also most > likely to be clued up when it comes to installation? Someone new to > Linux (or computing in general) isn't likely to buy a box without an > OS on it, just as a newly qualified driver isn't likely to buy a car > without an engine in it (unless they happen to be an auto-mechanic, > of course). That's true as long as the price is the same. Other posters in this thread have given credible arguments why mainstream PC vendors have a similar cost whether they install Windows or not. If PC vendors nonetheless did offer a no-OS box at a lower price, people who are not capable of Linux installation would buy them and immediately call when they can't install their personal choice of Linux distro. As far as separating hardware from software issues, the suggestion of a live CD for hardware diagnostics is a good one. Unfortunately, when an unsophisticated user calls, you still have to spend time convincing them to run the hardware diagnostic CD first, and that costs you money. Even if you can prove the hardware is working properly, very few unsophisticated users would accept the situation they are left in, having spent money and yet without a usable computer. Returning the computer sticks the PC vendor with a used machine that they have to retest before selling it at a discount, and the original customer has to pay more money for a pre-installed OS box. This is a lose-lose scenario, so you can't fault PC vendors for trying to avoid it. -- Seth Goodman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: Woohooo! Dell + Linux
Celejar wrote on Thursday, March 29, 2007 9:27 AM -0600: > That's what I never get about this whole business; I want them to do > linux to *lower* the cost by the cost of the windows license. I > suppose they're targeting people who want the convenience, not the > cost saving. I think that's exactly right. > I'd actually rather do the install myself, to customize it properly, > so I suppose what I really want is a no OS box, cheaper by the cost > of a Windows license from the equivalent Windows one. I believe that > they offered no OS boxes (with FreeDos, IIRC) at least at one point, > but I don't think they were cheaper than the Windows ones. Most people could not complete a Linux install without a phone call to tech support. I suspect that's one part of the reason there are so few no-OS boxes. When the install doesn't turn out right, their first call is to the people who sold them the hardware, even though that's the least likely place to have a problem. Technically sophisticated users do not tend to do this, but that's a pretty small market. -- Seth Goodman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: SMTP and ports 25 and 1025.
Matus UHLAR - fantomas wrote on Sunday, March 18, 2007 9:39 AM -0500: > On 18.03.07 14:13, Albert Dengg wrote: > > and everything that is for communication with the users can in > > prinziple run on any port you want, since you can tell then how to > > configure your clients, but there is no mechanism to tell other > > smtp servers "talk to me on port 666" or something. > > Yes, and ... ? I miss your point. Of course you can run any service > on any port. But there's good standard on what services run at what > ports and using different port is usually harder to configure, > detect etc etc... so better us well-known (assigned) ports. Actually, there is a standardized way to communicate ports for a given service via DNS: SRV records. Except that almost nobody uses them :) Since this mechanism did not exist until recently, MTA's pay no attention to it, as far as I know. -- Seth Goodman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: How to cool my cpu temperature?
Douglas Tutty wrote on Monday, January 08, 2007 8:02 AM -0600: > On Sun, Jan 07, 2007 at 11:52:57PM -0600, Seth Goodman wrote: > > Douglas Tutty wrote on Sunday, January 07, 2007 4:20 PM -0600: > > > > > Most electronics are designed for an ambient (to them, not the > > > case) temperature of 25 C max. > > > > It would be nice if we could assume that when designing hardware, > > but it isn't realistic. Even for a benign laboratory environment, > > we normally assume 40 degrees max ambient, which means the air and > > all surfaces surrounding the case. Industrial electronics are often > > designed for 50 degrees ambient with the case interior being 15 > > degrees higher. > > > You mean that if you take a number off a chip and look it up in the > manufacturer's datasheet it will say it will tolerate an ambient temp > of 50C? I'm not necessarily thinking of a major heat source like a > CPU/GPU or a power transistor but a simple TTL or CMOS support chip. > What about the clock occilator? They __used__ to go haywire if you > let them heat up too much. > > I'm not saying that the support chips won't work at higher temps but > it shortens the bathtub curve. Its one of those rules-of-thumb: if you > can't leave your thumb on the chip comfortably, then its too hot. > Mil-spec has a different rule of thumb of course. Then its not your > thumb but a delegated thumb:-) Electronics designed from the outset > for extreme environments will of course work in them. E.g. automobile > stuff, Mars rover, pacemakers (water cooled at 38 C). The OP I think > was talking about a regular consumer-grade computer so I limited my > focus to that. While your rule of thumb is certainly safe, it's overly conservative. Here's some explanation. Integrated circuits today come in a few general temperature ranges: commercial 0 to +70 degrees industrial -40 to +85 degrees automotive -40 to +125 degrees military -55 to +125 degrees These temperature ranges refer to the ambient temperatures of the chip environment, which means the air and circuit board temperatures. It is not the package (case) temperature that you mentioned. Regardless of the ambient temperature rating, the operating limit is 125 degrees junction (die) temperature for silicon. Below this temperature, the failure rate is temperature dependent and roughly doubles for each ten degree increase in junction temperature. While every application has different reliability and operating life requirements, most applications can tolerate junction temperatures of 110 degrees for smaller packages. Manufacturers normally select IC packages to give a junction to ambient temperature difference of around 20 degrees. This gives a maximum case temperature of around 100 degrees and an ambient temperature of 90 degrees. For commercial grade parts, the limit is 70 degrees ambient for the package, so case temperature might be 80 degrees. You shouldn't operate at the limit, but there's no problem with a 60-70 degree case temperature for many applications. This takes some care, but it is not unusual in scientific and industrial equipment. Large scale integrated circuits that dissipate a lot of power are a different matter. These chips are more failure prone because of several factors. The primary reason is that there are so many I/O connections that the probability of a single failure is much higher at a given junction temperature. You use heat sinks to limit the junction to ambient temperature difference and keep the ambient temperature somewhat lower than for the smaller packages. Still, it is overkill to require that case temperatures never exceed 50 degrees. > How can a laboratory environment of 40 C be called benign? I conk out > at 28 C. So do I, but we're soft :) Equipment is still expected to work in a rack, where temperatures are higher than in the room, or in a closet with less than ideal airflow. Laboratories often don't have high-capacity cooling systems with backups. And as Hugo points out, air conditioning is terribly expensive in some places and may not be reliable even when present. -- Seth Goodman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: How to cool my cpu temperature?
Douglas Tutty wrote on Sunday, January 07, 2007 4:20 PM -0600: > Most electronics are designed for an ambient (to them, not the > case) temperature of 25 C max. It would be nice if we could assume that when designing hardware, but it isn't realistic. Even for a benign laboratory environment, we normally assume 40 degrees max ambient, which means the air and all surfaces surrounding the case. Industrial electronics are often designed for 50 degrees ambient with the case interior being 15 degrees higher. -- Seth Goodman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: How to cool my cpu temperature?
Surachai Locharoen wrote on Saturday, January 06, 2007 12:42 AM -0600: > polling_interval was set to 2, I changed this to 30 and observed that > sometimes the CPU temp spiked at 102, 105, 107 but for no more than 1 > second then immediately dropped back to sub-100. No instability, so > could be a glitch? > > Sometimes Linux will hit 100+ on 30 seconds and halt. If the readings of around 100 degrees C are accurate, this is too hot for a processor die. While you can run power semiconductors that hot and still achieve acceptable reliability, this is not reasonable for a package like a processor. The primary failure mode is bond wires opening, and it is strongly temperature dependent. A typical power device has 3 bond wires, while a processor has several hundred, so the overall failure rate for this type of package gets too high at a much lower temperature. -- Seth Goodman
RE: How to cool my cpu temperature?
Mike McCarty wrote on Saturday, January 06, 2007 7:48 AM -0600: > The two most common causes of PS failure are spikes on the AC and > failing fans or otherwise obstructed air flow. Transients in the AC line causing damage to power supplies is a design issue for the supply. We have known for years how to protect supplies from line transients and how to prevent transients from reaching the supply outputs. While the energy in line transients and the power line impedance are statistical quantities, the root cause of this failure is inadequate design. It is not normally related to production quality. Even on well-designed power supplies, the fan is far more likely to fail than any other component. It is not difficult to have the supply gracefully shut down if the airflow stops for any reason, but this feature is often absent from consumer-grade PC power supplies. -- Seth Goodman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: timezone and clock error
Dean Allen Provins wrote on Thursday, November 02, 2006 2:20 PM -0500: > Hello: > > It seems that the PC clocks here in Alberta are still on daylight > savings time. This is odd as Alberta's clocks switched back last > weekend. > > /etc/timezone contains: > > Canada/Mountain > > Anyone know how to fix them? Is this by any chance a dual-boot system with the hardware clock running on local time to accommodate Windows? If so, it is possible for Windows and Linux to fight when daylight savings time (DST) starts or ends. This problem is due to Windows maintaining the hardware clock in local time and keeping track of whether it has adjusted for DST in a disk file that the other OS's don't know about. There are various hacks to fix this, none of them satisfactory. Until Windows decides to reliably support a UTC hardware clock, I suspect the only workaround is to ask Linux to treat the hardware clock as local time and enable ntp in both operating systems. This fails if the time servers are unreachable at boot time right after Windows updates the hardware clock for a change to or from DST. -- Seth Goodman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: Petition about the Firefox trademark problem
Hans du Plooy wrote on Monday, October 23, 2006 7:19 PM -0500: > Why don't they just put it in the non-free repositry? That does seem sensible. Mozilla appears to be exercising the same right that Debian explicitly reserves for one of its logos. If it's reasonable for Debian to protect its trademarks (I believe it is), than so it is for Mozilla. Replacing the graphics with your own and tacking on a name formulated as a slight is very poor press for FLOSS. -- Seth Goodman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: NTP weirdness
Roberto C. Sanchez <[EMAIL PROTECTED]> wrote on Tuesday, October 17, 2006 2:25 PM -0500: > $ ntpq -p > remote refid st t when poll reach delay offset jitter > > yauco.connexer. .INIT. 16 u- 10240 0.000 0.000 4000.00 > maracaibo.conne .INIT. 16 u- 10240 0.000 0.000 4000.00 It looks like you can't reach your servers, or you reach it and then discard it (ntp determines it is a 'falseticker'). The first character on each server line is a space, which indicates its status as a server is 'reject'. Also, both servers show up as stratum 16, which is not reasonable since each of the two servers was configured to use three low stratum servers. If working, you would see a '+' in the first column, the 'stratum' column would show 2 or 3, the 'when' column would show a number less than the poll column, the 'reach' column would typically show 377, and the 'delay', 'offset' and 'jitter' columns would show non-zero values. When a machine can't reach any of its designated servers, it uses the local hardware clock, so that's probably why it's drifting. Once you resolve the reachability issue, you might check whether a drift file is declared in ntp.conf. The drift calculation takes about a day to stabilize and with no drift file declared, ntp doesn't write this out at shutdown and must start over each time the machines reboots. To do the peering that Henrique suggested, you declare the other server as a peer. Here's what ntp.conf would look like for yauco.connexer.com: driftfile /var/lib/ntp/ntp.drift server ntp2.usno.navy.mil server ntp-1.vt.edu server ntp-2.vt.edu peer maracaibo.connexer.com -- Seth Goodman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: Petition about the Firefox trademark problem
Tyler wrote on Tuesday, October 17, 2006 6:42 AM -0500: > Michael M. wrote: > > > > I don't think Debian does the same thing with its "Official Use > > Logo." The logo indicates that the project officially has been > > approved by Debian, but it doesn't imply any sort of control over > > the project by Debian. > > > > But how does Debian decide to approve a project? Do I just ask them > nicely, and then modify the code to my hearts content? Debian doesn't > require a formal code review, but could still revoke their trademark > if they don't like the code, or for any other reason. My question as well. If someone starts with a snapshot of an official Debian release, follows the Debian packaging guidelines and fully complies with the GPL, is there any basis for denying their continued use of the official Debian logo? -- Seth Goodman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: Petition about the Firefox trademark problem
Michael M. <[EMAIL PROTECTED]> wrote on Saturday, October 14, 2006 8:11 PM -0500: > In other words, the Firefox logo indicates that the browser *is* > Firefox; the Debian Official Logo indicates that the project using > the logo *uses* Debian. That sounds reasonable, but for one problem. How much Debian must something use before using the logo? Asking that differently, how much can you change before you must take the Debian logo off? -- Seth Goodman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: Linux and Newest Hardware
Johannes Wiedersich <[EMAIL PROTECTED]> wrote on Thursday, October 12, 2006 11:58 AM -0500: > Seth, > > I think you mix up two different things: > - if you want to by recent hardware, as a good rule, it is not cheap. > - if you settle for not so recent hardware, it will be cheaper and it > will be supported by linux. > > Personally on a low budget, I don't see the reasoning in buying the > latest hardware, that is a factor of say 2 more powerful at a factor > of 4 higher prices. > > On the other hand: if you are looking for good and recent hardware it > will be expensive, but if you select a linux friendly manufacturer it > will be also supported by linux. OK, let me tell you why I believe I'm not mixed up ... at least on this. I actually said commodity hardware. I meant the stage where hardware and drivers are stable, there are multiple mainstream suppliers and they are priced as commodities. With the short product lifetimes of consumer electronics, that means recent, though not bleeding edge. What exactly is that today? It's completely a matter of opinion. My notion is something like a 2GHz 64-bit AMD or 3GHz Intel processor, 256MB DDR RAM, graphics chipset on motherboard, USB2.0 ports, DVD writer and a 150MB+ (modern) hard drive. Purchasing a USB keyboard or wireless mouse at the local store should neither require a trip to the list nor compiling a kernel. Such systems are plentiful, stable and cheap from mainstream manufacturers, even with the preinstalled commercial O/S. Buying commodity hardware like this from a shop that preinstalls Linux, or is at least responsible for compatibility, will normally cost a lot more. It is extremely hard for small shops to compete with the WalMarts, eMachines and Microsofts of the world. They can only do so by not making much profit, or being subsidized by their customers' good will. -- Seth Goodman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: Linux and Newest Hardware
Roberto C. Sanchez <[EMAIL PROTECTED]> wrote on Thursday, October 12, 2006 9:22 AM -0500: > Really? I spent about $400 on a small form-factor PC from iDotPC (not > including monitor). They "support" Linux (their default OS unless you > choose something else is Linspire). There are also tons of smaller > vendors out there who support Linux in way or another. That means you > probably won't be able to get the rock-bottom WalMart PC for $200 and > still be certain that everything on it works in Linux. But, for a > midrange PC, I'd venture to guess that something from a smaller vendor > would be within $100 of a comparable Dell offering. I took a look at their site and the hardware is nicely packaged, but hardly comparable to commodity PC's. I'm sure they are a good vendor (they support Linux), but these are basically 800MHz PIII's. Can you even new buy commodity hardware like that? While we can extol the virtues of minimalist systems, and I personally like that approach, it's not a good general answer. Lack of support for current generation commodity hardware is an issue, and we might as well be honest about it. > I guess that question you need ask your self is "Will it take more than > $100 of my time to make the Dell PC work with Linux?" That depends on how much you pay yourself :) > Or even "Is it worth $100 to know it will Just Work(TM)?" Yes, if you have an extra $100 and you don't mind buying previous generation hardware. If you want current generation hardware, you're going to spend more than that. > Not just that, but if you > buy from a smaller vendor who supports Linux, you take a copy of the > invoice and then snail mail it to Dell with a letter saying "I tried to > buy a consumer level PC from you guys with Linux, but I you would not > sell me one, so now my money goes to vendor X." LOL. This is clearly worth something, but it is using your money to make a statement. Not everyone has extra disposable income for that purpose. The bottom line is that unless you have too much spare time, or are willing to use obsolete used machines (my personal choice), you're going to pay more for a lot less hardware. -- Seth Goodman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: Linux and Newest Hardware
Roberto C. Sanchez wrote on Thursday, October 12, 2006 12:12 AM -0500: > The short answer is to only buy systems or components from vendors who > support Linux. Fine if you have enough money to make a statement, but that leaves out most vendors of affordable hardware. It's much cheaper, even with the preloaded throw-away O/S. -- Seth Goodman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: Yes! a free legal source for downloadable music!
On Wednesday, October 04, 2006 2:46 PM -0500, [EMAIL PROTECTED] wrote: > [EMAIL PROTECTED] wrote: > > How do i get some music > > This may not be what you were looking for, but it's an interesting > find for legal, free downloads: > > http://www.irateradio.com/ That's an interesting service, thanks for the link. For some Creative Commons licensed music (also film and audio books), try http://legaltorrents.com. You need a bittorrent client. -- Seth Goodman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: MOBILE PHONES AT VERY LOW PRICE OFFER. (reporting list spam)
On Thursday, September 28, 2006 10:48 PM -0500, David E. Fox wrote: > On Thu, 28 Sep 2006 04:47:39 -0500 > "Seth Goodman" <[EMAIL PROTECTED]> wrote: > > > > Spamming activities that are now illegal in the U.S.: sending > > UBE to electronically harvested addresses, forging headers, > > deceptive subject > > 99% of the spam (at least) violates one or more of those > restrictions. True. My point was that this law, sadly, establishes the principle that spamming is legal, as long as you abide by the rules. There is no requirement to opt in and they can spam you until you opt out. I believe you are right that most spam violates this law, but what good is it if no one will enforce it? Worse yet, spammers have the option to continue spamming legally. -- Seth Goodman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: spamcop
On Thursday, September 28, 2006 6:26 PM -0500, Miles Bader wrote: > Anyway, the point is that simplistic assumptions like "if it > arrives at a spamtrap, it must be spam" are just that -- simplistic. > Spamcop ought to have measures in place to deal with the inevitable > cases where their assumptions turn out to be wrong. If an address has never sent email, it is obviously impossible for it to opt in to anything and any mail that it receives is unsolicited. If someone guesses an address at a domain and sends it mail, that is also unsolicited. If someone makes a typo when entering their email address, it may be an honest mistake but it is still an unsolicited message and it came from your server. You are responsible for everything that comes out of your server, intentional or not. I suppose one could postulate that DNSBL's should all be required to have a human view every potential listing, to avoid a small number of false positives due to honest mistakes. OTOH, it would be just as unreasonable to suggest that a large public list such as Debian-user should have an administrator manually approve every confirmation email before sending, to avoid any abuse to innocent third parties. Both are impractical. One can manipulate legitimate servers into abusing innocent third parties, or to falsely incriminating themselves as spammers. When that happens, it is incumbent on the owner of the server to take action. That's part of the responsibility of running an server on the net. > Unfortunately many anti-spam sites, in their zeal to attack spam, > seem to not care very much about what collateral damage they inflict. While there is no excuse for operating a DNSBL without a reasonable level of care, it is not possible to manually review every listing/delisting event. Nor is it possible to avoid all errors in an automated process where forgery is possible. Mistakes will occur from both ends and both parties have to cooperate. Thumbing our noses at a DNSBL that many people consider worthwhile is not good policy. -- Seth Goodman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: MOBILE PHONES AT VERY LOW PRICE OFFER. (reporting list spam)
On Wednesday, September 27, 2006 3:33 AM -0500, Johannes Wiedersich wrote: > Sending spam is illegal in many countries including > the EU and the US, so the people responsible for servers in these > countries are legally obliged to take action, if they are notified. That's not true for the U.S. Several years ago, the U.S. Congress passed the unfortunately named [yes you] CAN-SPAM Act of 2003. The law uses the opt-out principle, thereby legalizing spam, except for specific prohibited practices. That is, any entity is free to send you UBE until you opt out. You must notify each individual entity whose mail you do not wish to receive ... there is no way to globally opt out. Spamming activities that are now illegal in the U.S.: sending UBE to electronically harvested addresses, forging headers, deceptive subject lines, failure to provide a working opt-out mechanism, ignoring recipient's opt-out declarations and distributing addresses of people who opt out without indicating that fact. As a practical matter, your chances of being prosecuted for any of these are remote. -- Seth Goodman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: spamcop
On Wednesday, September 27, 2006 10:58 AM -0500, Michael Marsh wrote: > On 9/27/06, Kamaraju Kusumanchi <[EMAIL PROTECTED]> wrote: > > If murphy is sending spamtraps, it deserves to be listed. period. > > Um, murphy sends confirmation email to any address registered > through the web interface. Even if you changed this to > email-to-subscribe without a web option, addresses can be spoofed. > This isn't about spam coming from murphy, it's about a denial of > service attack against it. > > I suppose another option is to have the confirmations handled by a > different host, though this still allows an attacker to DoS the > confirmation server through spamcop, so that people using spamcop > can no longer subscribe nor unsubscribe. I agree with Michael: tricking a server that responsibly sends out confirmation messages into sending one to a spamtrap is about denial of service. I also agree with Kumaraju that sending mail to spamtraps should get anyone listed. If your server is not otherwise a spam source, and the DoS continues, you should expect to get the server whitelisted. However, it is your responsibility, and not the DNSBL maintainer, to make sure this happens. It's a rather nasty form of DoS, as it uses an organization that tries to fight network abuse to cause problems for the FLOSS community. Worst of all, the Debian listmasters have swallowed the bait. That's why it is important, whether people like SpamCop or not, to arrange to get murphy whitelisted. Complaining that SpamCop is cluelessly administered won't convince many to stop using SpamCop, yet will convince some that the Debian community has an attitude problem. Either way, the people perpetrating the DoS win, though it turns out differently if we cooperate with SpamCop. -- Seth Goodman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: closing mailing lists (was: spamcop)
On Tuesday, September 26, 2006 1:17 PM -0500, David Jardine wrote: > On Mon, Sep 25, 2006 at 07:53:21PM -0500, Seth Goodman wrote: > > > [...] > > > I think the following would make Debian lists better for everyone: > > > > [...] > > > > 3) allow users to temporarily turn off list mail > > > Once you've got used to how a mailing list works, which the above > users presumably have, it's hardly a hassle to unsubscribe and then > re-subscribe later. That works for the vacation purpose, but that doesn't allow someone to subscribe without getting all list traffic. That inability is the main reason for not requiring someone to validate their email address before posting. If my local prairie restoration club can make people subscribe before posting, I don't see why Debian can't. You want help with invasive garlic mustard? Better subscribe :) -- Seth Goodman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: closing mailing lists (was: spamcop)
On Monday, September 25, 2006 8:08 PM -0500, Roberto C. Sanchez wrote: > IIRC, the Debian lists are powered by mailman. Have they just > disabled this functionality, or is it a technical/political issue? If they use Mailman, there is a feature to allow users to determine whether they receive list mail. This can be controlled from both the web interface and via email. There is also an administrative feature to require subscription before posting. -- Seth Goodman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: Mouse Problems with KVM Switch
On Sunday, September 24, 2006 11:38 AM -0500, aladdin wrote: > Yeah, I've tried that. In fact, every so often, I try it again > (you know the definition of insanity- trying the same thing over > and over again and thinking you'll get a different result;-). In > my case, it doesn't work. What if the next time would be the one that succeeds? -- Seth Goodman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: closing mailing lists (was: spamcop)
On Sunday, September 24, 2006 8:34 AM -0500, Stephen wrote: > On Sat, Sep 23, 2006 at 01:22:30PM -0500 or thereabouts, Seth > Goodman wrote: > > > You are right in saying there is no apparent way to subscribe > > without getting all the list traffic. Without this feature, it > > is impractical to require that posters first confirm their email > > address. > > Why ? I don't know of any e-mail list, (other than this one) that > doesn't require people to first confirm their address -- It's > pretty much a standard practise. Andrei pointed in http://lists.debian.org/debian-user/2006/09/msg01837.html that for an occasional poster to a high volume list, it is a burden to require them to receive all list traffic. It's not a problem when the list allows subscribing for posting only (i.e. majordomo 'nomail', Mailman 'set delivery off'). Debian lists don't provide this feature. It would also be helpful to people who go on vacation, or get very busy, and want to temporarily stop high-volume mail sources. You're quite right in pointing out that most mailing lists require registration before posting in order to control spam. That doesn't mean they require the user to receive all list traffic. I quite agree with Hans in http://lists.debian.org/debian-user/2006/09/msg02163.html that anyone who can't successfully respond to a confirmation email probably won't be able to deal with Debian. I think the following would make Debian lists better for everyone: 1) allow users to subscribe for posting only, 2) require users to subscribe before posting and 3) allow users to temporarily turn off list mail -- Seth Goodman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: closing mailing lists (was: spamcop)
On Friday, September 22, 2006 12:15 PM -0500, Andrei Popescu wrote: > "Seth Goodman" <[EMAIL PROTECTED]> wrote: > > > On Thursday, September 21, 2006 3:38 PM -0500, Andrei Popescu > > wrote: > > > > > It's not nice to require *everybody* to receive 100-150 > > > mails/day just for a simple answer. > > > > There's no reason you have to receive list traffic. You can > > already do this if you subscribe via email. There is no reason > > the web portal couldn't have the nomail option as well. > > Where is this documented? I sent a 'help' to majordomo, but this > command was not listed in the response. My recollection of this was completely wrong. Sorry for the misinformation. 'nomail' is a majordomo command, so I obviously confused another list with this one. The docs for the Debian list servers do not contain any information on the equivalent feature in their list software (do they run Mailman?) nor have the list maintainers responded to my questions so far. You are right in saying there is no apparent way to subscribe without getting all the list traffic. Without this feature, it is impractical to require that posters first confirm their email address. -- Seth Goodman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: spamcop
On Thursday, September 21, 2006 8:49 PM -0500, John Kelly wrote: > On Thu, 21 Sep 2006 16:33:26 -0500, "Seth Goodman" > <[EMAIL PROTECTED]> wrote: > > > > But once you get a grip and hang on for a while, you realize > > > that sacrificing 2% is a piece of cake. > > > If users value reliably getting their messages more than they > > value spam reduction, which seems to be the case, it will cost > > you. Large system admins are not fools. They have tried this > > and people don't accept it. > > Is that your experience, or speculation? I do not operate large MTA's, though I have known people who do and they are definitely not fools. They understood that testing for forward DNS != reverse DNS at connection time is an extremely cheap way to reduce the spam load. Some actually do reject for this. The reason that many don't is the level of user complaints they experienced when they tried, or experiences of other operators they know. If most of the large MTA's implemented this policy, you would no longer see a significant false positive rate, as everyone who could would be forced to comply :) There are still a significant number of systems in the developing world whose providers don't delegate reverse DNS or who can't set it for you. Taking a hard-line here would prevent many people from operating a useful mail server. This is the same reason that the sensible RMX proposal for tagging hosts that are permitted to send mail on behalf of a domain failed: the reverse DNS system is in poor condition in many places. People have known for quite a while that forcing systems to take responsibility for their outbound mail flow is the primary issue. That means forward DNS, reverse DNS and EHLO name should all agree. It also means that MTA's must control submission rights, either by IP or preferably with SMTP AUTH, so users can also submit mail remotely. Furthermore, MTA's can limit the use of sender identities to those that the submitter has a right to use. If your network includes insecure systems, it is prudent to force them to submit mail to a smarthost and use both virus and spam filters on outgoing traffic. That small set of best practices would both make it easier for sending MTA's to curtail abuse and then take responsibility for what they send. However, even that modest set of requirements has been too much for the largest providers to implement for fear of the breakage it would cause. -- Seth Goodman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: closing mailing lists (was: spamcop)
On Thursday, September 21, 2006 3:38 PM -0500, Andrei Popescu wrote: > It's not nice to require *everybody* to receive 100-150 mails/day > just for a simple answer. There's no reason you have to receive list traffic. You can already do this if you subscribe via email. There is no reason the web portal couldn't have the nomail option as well. -- Seth Goodman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: spamcop
On Thursday, September 21, 2006 2:33 PM -0500, John Kelly wrote: > On Thu, 21 Sep 2006 14:53:28 -0500, "Seth Goodman" > <[EMAIL PROTECTED]> wrote: > > > > The improper DNS false positive rate is low, less than 2%. > > > It's a pity, but very few people think in terms of winning the > > spam war anymore. Most systems would consider this false > > positive rate unusable by a large margin. The larger the > > provider, the less workable this solution. > > That's the fear factor. > > But once you get a grip and hang on for a while, you realize that > sacrificing 2% is a piece of cake. If users value reliably getting their messages more than they value spam reduction, which seems to be the case, it will cost you. Large system admins are not fools. They have tried this and people don't accept it. It works nicely for small systems but the administrative overhead makes it hard to run a large system that way. It's also grossly unfair to people in some developing regions who don't have control over their rDNS and we can't tell them to "get a grip". I hope things change and we can require forward == reverse in the future. If that happens on a large scale, spam-friendly providers can just use dynamic IP hostnames that are not detectable via regexp :) -- Seth Goodman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: spamcop
On Thursday, September 21, 2006 11:39 AM -0500, Stephen wrote: > This is why debian-user is being constantly blacklisted -- So the > onus is on Debian to fix things on their end. Strongly agree. Spam from USENET is part of it, but SpamCop listed the server because of messages to a spamtrap. If this is correct, it had to be a confirmation message :) Spam trap addresses are secret, so there's no way to stop this except by talking to the DNSBL maintainers. -- Seth Goodman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: closing mailing lists (was: spamcop)
On Thursday, September 21, 2006 1:44 PM -0500, Matus UHLAR - fantomas wrote: > I don't think that closing mailing lists is the right way to fight against spam. The question is whether requiring a user to answer one confirmation message before posting is any real burden. You have to send mail to post, so is it really a burden to first confirm your email address? Isn't it worth one confirmation message to be able to ban an address that spams? -- Seth Goodman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: spamcop
On Wednesday, September 20, 2006 5:48 PM -0500, John Kelly wrote: > On Wed, 20 Sep 2006 18:01:38 -0500, "Seth Goodman" > <[EMAIL PROTECTED]> wrote: > > > > require matching DNS, forward and reverse <...> > > some large servers won't use it. > > I don't know of any. But if there really are some sending > legitimate mail, I would be interested in collaborating to maintain > a whitelist of them. Need to be LARGE though, to be worthwhile. This is large system receiving policy, not the large system configuration. All the large senders I know about have properly configured DNS. There are far too many small MTA's with misconfigured DNS, however, for a large MTA to ban without a steady stream of customer complaints. You seem aware of this problem in your later post: On Thursday, September 21, 2006 9:53 AM -0500, John Kelly wrote: > The improper DNS false positive rate is low, less than 2%. Admins > must accept some collateral damage, if they expect to win the war. It's a pity, but very few people think in terms of winning the spam war anymore. Most systems would consider this false positive rate unusable by a large margin. The larger the provider, the less workable this solution. While I would love to have this be an absolute requirement for SMTP, there are too many incompetently administered systems from which you must accept mail, and large parts of the developing world do not routinely delegate rDNS. This is a nasty problem that won't go away quickly. > There is resistance to this idea, because some admins fear losing > any legit mail. But given that the false positive rate is low, it > should be feasible to develop and maintain a whitelist of > legitimate mail servers lacking proper DNS. I'm not volunteering, > but it's an idea that has merit. This works fine for small systems but doesn't scale. Admins can't be bothered whitelisting everyone's one or two correspondents with broken DNS, and almost everyone has some, even in the developed world. Customers will not tolerate _their_ correspondent's mail being blocked when those systems are not abusing any networks. > The list may also urge offending admins to set up proper DNS, like > when newspapers publish a shame list of people who have not paid > their property tax. We already have rfc-ignorant and it is widely ignored. The only people who care are the ones who would never get on that list in the first place. -- Seth Goodman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: spamcop
On Wednesday, September 20, 2006 3:19 PM -0500, John Kelly wrote: > On Wed, 20 Sep 2006 15:33:05 -0500, "Seth Goodman" > <[EMAIL PROTECTED]> wrote: > > > Did anyone investigate the problem and make this request? > > If they're not self motivated, I have no incentive to use them. I don't particularly want to defend these guys. I'm defending spamtrap-based DNSBL's, not any specific list. Expecting anybody to notice that a server from any friendly organization was listed is a bit much. If someone from Debian contacted them and didn't get anywhere, that would be a different story. > > Any DNSBL is subject to gaming by spammers who would like to > > curtail the use of DNSBL's in general and spamtraps in particular. > > No, not any. Just spamtrap based lists poorly administered. Spamtraps are easily manipulated for any server that sends out confirmation messages, and some lists are better than others. While I don't like the idea that a Debian server is listed anywhere, it is reasonable to expect that someone would contact the list maintainers. In the case that it is impossible to avoid sending mail to a spamtrap, as for any machine that sends confirmation messages from a web form, and the server admins are known to deal with abuse complaints, then whitelisting is appropriate. However, it is not unreasonable to expect that someone would request it. > My three step defense works fine without spamcop: > > 1) require matching DNS, forward and reverse I personally advocate this approach, although it is not strictly RFC-compliant, so some large servers won't use it. > 2) use regex tests for dynamic/dialup host names (works because #1 > strictly enforced, and thus hostname is known) Even if you don't reject on !exist(reverse)||(reverse != forward), you can still use the reverse on the IP for the regexp and reject for "local policy" when it matches. > 3a) query dynablock.njabl.org for any dynamic hosts missed by my > local checks in step 2 > > 3b) query a few GOOD, RELIABLE dnsbls: > > dnsbl.njabl.org > list.dsbl.org > sbl-xbl.spamhaus.org This is a very reasonable set of lists. I believe that dnsbl.njabl.org is a subset of xbl.spamhaus.org, so the first query is redundant (unless you are trying to limit spamhaus queries). -- Seth Goodman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: spamcop
On Wednesday, September 20, 2006 1:55 PM -0500, John Kelly wrote: > When spamcop admins don't have enough sense to whitelist servers > like murphy.debian.org, it's time to abandon them Did anyone investigate the problem and make this request? Any DNSBL is subject to gaming by spammers who would like to curtail the use of DNSBL's in general and spamtraps in particular. I don't think that responding as the spammers would like is in our interest. -- Seth Goodman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: spamcop
On Wednesday, September 20, 2006 7:22 AM -0500, John Kelly wrote: > For the second time in the past few days, spamcop has listed > murphy.debian.org. That's it. I'm done with spamcop! The listing is at http://www.spamcop.net/w3m?action=checkblock&ip=70.103.162.31 (expires in nine hours). It appears the machine sent mail to a spamtrap. It has been listed five times in the last six months. I think that's worth looking into. If it did indeed send mail to a spamtrap, the listing is justified, even if it's rather inconvenient. If that machine has become a target for spammers who would like to make spamtraps useless (for example, taking any action that would send an automated confirmation message from a high-volume server to a spamtrap address), the answer is not to abandon SpamCop. Any DNSBL that uses spamtraps is susceptible to this ploy. I'm willing to look into a solution if nobody else is interested. -- Seth Goodman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: Linux Will Get Buried (Off)
On Friday, September 15, 2006 3:58 PM -0500, Curt Howland wrote: > On Friday 15 September 2006 16:46, "Seth Goodman" > <[EMAIL PROTECTED]> was heard to say: > > I don't think that turning a political affiliation into a dirty > > word benefits anyone. It certainly prevents rational discourse. > > Politics has nothing to do with rational discourse. There are thugs > with the power to take other peoples money, and there are the people > so robbed. That's it. > > "Politics" are the lies told by the former to keep the latter from > killing them. The individual making the accusation/insult here also has politics. No one can say another's political affiliation makes their ideas worthless without calling their own ideas into question. It's also just plain rude. -- Seth Goodman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: Linux Will Get Buried (Off)
On Thursday, September 14, 2006 10:28 PM -0500, Steve Lamb wrote: > Paul Johnson wrote: > > How am I a proponent of Big Brother? I would say that's a pretty > > empty accusation, especially coming from someone who doesn't know > > me. > > Your publicly announced political affiliation pretty much is > all that is need to be known about you. I don't think that turning a political affiliation into a dirty word benefits anyone. It certainly prevents rational discourse. -- Seth Goodman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: is it possible to create a black box with debian?
On Wednesday, September 13, 2006 7:47 AM -0500, Michelle Konzack wrote: > Am 2006-09-11 21:59:36, schrieb Ron Johnson: > > > > Ha Ha Ha !!! > > > Local access ? > > > Game over. > > > You lose. > > > > Sure, if it's a cheap plastic case. I'm sure there are heavy-duty > > cases with stronger locks. > > ...with activated detection of case manipulation and > automatic self-destruction using a half pound C4? This might make service calls more stressful. -- Seth Goodman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: How to check ink level on HP Deskjet 5500
On Thursday, August 17, 2006 10:23 AM -0500, Paul Scott wrote: > Marc Shapiro wrote: > > > > > > CORRECTION: I just found hp-toolbox, which has a 'Supplies' tab > > showing the installed cartridges and should have the ink levels. > > But it does not seem to show any ink in either cartridge. The > > printer is printing fine, so I obviously DO have ink. Is there > > something that I am doing wrong? > > I have the latest HP Toolbox on a Windoze 2K machine and it also > shows no ink when the printer is printing just fine. AFAIK, I also have the latest HP tools for my OfficeJet5500 on a Win2K box and it does show ink levels, but only when logged in as an administrative user :) Nice tool for some of the people some of the time. This is, by far, the worst printer software package that I have ever used. Aside from things that don't really work, it runs five persistent processes with a total of nineteen threads and takes up 26MB of memory. It was apparently written and (not) supported by their operation in Bangalore. I hope the Linux tools were not derived from this sorry package. On installs of the earlier versions of this software, many other functions only worked for an administrative user. When I called in to report this, they calmly told me, "We recommend all users run as administrator all the time". When I suggested that some people consider this a security issue, she ignored my comment and continued to the next helpful suggestion. This was a recipe for editing the registry to make _all_ items owned by the administrator downgraded to read/write/execute permissions for everyone. OK ... I can appreciate artful deviousness. It took me a while before I figured out she did not seem to understand my replies, except to determine whether I accepted her current suggestion. If I didn't, she just read me the next entry on her script sheet. This explains why it didn't sound at all like a normal conversation. By the end of the call, it was apparent that though she comprehended little English, she could read a prepared script with excellent diction, which was why she got the job. After escalating subsequent calls up the food chain, I learned that there are no tech support people to whom you can speak that have any real understanding of the products for that entire product line. There was no option of speaking to anyone in the U.S. concerning these products, and calls made to U.S. offices were quickly referred back to Bangalore. HP apparently doesn't want to know. -- Seth Goodman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: Open Source Supported Graphics Cards
On Monday, August 14, 2006 6:23 PM -0500, Katipo wrote: > Seth Goodman wrote: > > > You are the sysadmin for these two Windows-type users, which is > > the only environment in which they can realistically use Debian. > > Take away the sysadmin or Linux mentor and the chances of them > > being able to configure a system that is as useful to them as > > their Windows boxes are slim to none. > > > When I started out, all I had to master were the intracacies of > apt-get. You just lost 80%+ of the Windows crowd right there. > Gnome gave me everything else I needed to be productive. > If I needed a word processor or spreadsheeting facility, it was > there. Frankly, I got a lot of stuff, as you do with Windows, that > I didn't need. But with Gnome, I found I could remove what I didn't > want, and that potential is what got me started. > With Windows, you don't do that because you're not allowed to. > > The only things I had to go fishing for were aspects such as sound. > This bothered me initially, but I've found, over time, that > evolution is a process that brings its own rewards. > Initially, it might seem like a big investment. This is the attitude of most people with technical aptitude. You're forgetting that most computer users do not have technical aptitude, they have no interest in getting it and therefore they are not going to get it. For them, investing time is, sadly, a rather complete waste. They more or less refuse to learn any basics of computer technology, or if they try, they are unsuccessful, so they are unable to understand why the system operates the way it does. They can memorize a few things, if they must, like they do with their Windows boxes. Anything more than that is not going to happen, no matter how many times you and I tell them it will serve them well in the long run. > But in time, if your sys admin only needs to take care of his/her > server, this means a greater saving for any IT department. Most employers of mine would disagree with you. They prefer engineers to do engineering, managers to manage and customer service staff to talk to customers. Paying any of these groups to become amateur sysadmins turns out to be a rather poor investment and leaves real work undone. That's why IT departments exist. > A 'mentor' is not a permanent position, and many of us never even > had one beside this list. That's because you had the aptitude and desire to learn. If you didn't have this ability, you could never be self-sufficient and would always need the guru. I'd say that everybody on this list has the ability and desire to learn, and some are here to teach as well. I'm also saying that most non-technical computer users are not capable of learning Debian, as it exists today. While some may disagree, I consider that a problem. -- Seth Goodman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: Open Source Supported Graphics Cards
On Monday, August 14, 2006 5:48 PM -0500, Katipo wrote: > Seth Goodman wrote: > > If that were true, the vast majority of us, who used to be Windows > users, wouldn't be here. Right. I use Windows for most of my work projects, and before that, I used Unix for many years. I'm not a casual computer user, and I doubt you are either. I'd wager that most people here are not typical Windows users. Are you comfortable with the concepts of DHCP, DNS and file system partitions? If so, you're not a typical Windows user. _That's_ what we're dealing with. Pretending it were not so will not make it go away. > You can add your lone voice to the increasingly agitated Microsoft > endorsers, as you see fit - we're all for free speech here, but I > don't think it's going to slow the gradual migration percentage > away from Windows considerably. I have no idea where the sentiment you are criticizing came from, but it wasn't from anything that I posted. It is very helpful, and doesn't make one an "endorser", to look at what your worst enemy has done and recognize when they've done something useful. If you want to prevail over something, and it is my fondest hope that someone, _anyone_, prevails over this bunch of corporate thugs, you would do well to notice what they do that works, as well as their failures. I respectfully disagree that the lack of a reasonable installation and desktop experience for the non-technical user will not slow down the gradual migration away from Windows. It already has. Linux has established itself as the preferred choice for most server applications, and it has a good chance of dominating that market. The non-technical desktop user, who is not supported by an IT staff, is another matter and a place that we need a lot of improvement to even gain a foothold. What do you suppose would be the browser market share today for FireFox if it were released only on Linux? > Microsoft's present marketing-blurb overtures in the direction of > free/open source scream that they are aware of it also. > Even that will quieten down, when the effluent from the quagmire of > their own creation fills their mouths, as they go under for the > final time. Nothing would make me happier than if I believed this. Unfortunately, they continue to do one thing right where the non-commercial Linux distros have consistently failed, and this prevents the scenario that you suggest from happening. That is, they provide a platform that the non-technical user can install and maintain without a guru at their disposal. We're not there, and I don't see much motion in that direction. If you expect the Windows crowd to start reading Linux books and becoming computer-literate, that's not realistic. There will always be more people who don't read the books than those who do, and what _they_ choose will still drive the whole system. It doesn't matter how many times we tell them why we _know_ their machines are holier than a piece of Swiss cheese. They don't understand and it's just noise to them. As long as we insist on the current paradigm, Linux will continue to be the choice of professionals and largely unusable by the general public. There's no reason we can't make the product usable for the larger, computer-as-appliance group without diluting what it does for the software professional. -- Seth Goodman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: Open Source Supported Graphics Cards
On Monday, August 14, 2006 6:20 AM -0500, George Borisov wrote: > Anthony M Simonelli wrote: > > > > I just get a little upset when people want to mold Debian into > > something like a Windows clone. If you want that, try a > > Debian-derivative such as Linspire or Xandros. > > Spot on, dude. Does that represent the Debian position? I'd very much like to know. If so, I'll continue to use it in server applications and stop recommending it to friends who are not computer professionals. That would certainly make my life easier and Microsoft more profitable. Where does that leave open-source software? Well, I guess that will stay limited to the 10% market share reserved for any product designed for the cognoscenti. We can keep our install CD's right next to our Sony Beta-Max tapes. -- Seth Goodman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: Open Source Supported Graphics Cards
On Monday, August 14, 2006 11:52 AM -0500, Albert Dengg wrote: > On Sat, Aug 12, 2006 at 02:07:43AM -0500, Seth Goodman wrote: > > On Friday, August 11, 2006 10:39 PM -0500, Anthony M Simonelli > > wrote: > > <...> > > > You can get books that help. In fact, the Debian GNU/Linux 3.1 > > > Bible (ISBN 0-7645-7644-5) is a great book for those just > > > getting started with Debian and Linux and answers the first two > > > common tasks they'd need to know as well as installation help > > > and getting a desktop up and running. They also discuss > > > Internet and Intranet services such as web servers, printing, > > > file servers, FTP, etc, and it's only $40.00 (hey, you're not > > > paying for the operating system!) > > > > I don't need books like that because I can read the > > documentation. The average Windows user is not going to read it. > > They don't need to read books to fire up their Windows boxen, and > > they don't expect to read books to move to Linux. If it were up > > to snuff, they wouldn't need to. You're preaching to the choir by > > telling me that a technically adept person can make Debian do most > > common tasks without inordinate difficulty. The average computer > > user, OTOH, is a completely different story. > > well, the average windows install done by an average user does not > really work as it should, give all the security problems and worm > distribution, which is at least partly due to the fact that with > windows, everybody thinks they can do it themselves and know what > they are doing. At least they can do it, whether we approve of the results of not. That's not the case for Debian. If you have to hire a sysadmin to install and maintain the system, it is hardly free. Sure, it works well for any institution large enough to have an IT staff. Everyone else is effectively excluded unless they are willing and able to become computer jocks rather than doing their actual jobs. I really think we're unnecessarily excluding the largest group of people who could benefit from free, open-source software. I don't think we want to be saying that computers should only be used by those with access to competent IT staff. If that's the club's charter, I'm not a member. > ... > > my point is, there are different distros with different goals > and also i have 2 "normal users" here using debian without any > problems (both don't know pcs worth a damn and would also have > problems with windows)...i do the system administration and for > them it just works (and for me it is less work them administrating > a xp home install which does not have fs permissions where i have > to reconstruct all sort of system files they alter/delete be > accident... :-) ) You are the sysadmin for these two Windows-type users, which is the only environment in which they can realistically use Debian. Take away the sysadmin or Linux mentor and the chances of them being able to configure a system that is as useful to them as their Windows boxes are slim to none. Your example makes my point quite well. Unsophisticated users attempting to use Debian need an experienced user or sysadmin to show them how to do anything that is not quickly accessible through a GUI. Unsophisticated users can and do successfully configure and use Windows (and Mac) boxes every day without the benefits of sysadmins. They can't do a domain controller, LDAP or a mail server, but they can construct a functioning peer-to-peer network, share printers, access the internet and get their email. The fact that the resulting system is insecure is due to the horrific quality of the underlying operating system implementation, not the fact that there are sufficiently simple wizards and GUI's to allow them to configure their own systems. -- Seth Goodman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: Open Source Supported Graphics Cards
On Friday, August 11, 2006 10:39 PM -0500, Anthony M Simonelli wrote: > > > > That's a reasonable goal, even a good goal, if you are > > > > willing to remain a small, exclusive club. > > Actually, Debian is one of the fastest growing distribution > according to Netcraft: > > http://news.netcraft.com/archives/2005/12/05/strong_growth_for_debian.ht ml > > and Linux in general is making it's mark with companies such as HP, > IBM, and Google and around the world. The first line of that article is: "Debian is currently the fastest growing Linux distribution for web servers, with more than 1.2 million active sites in December." This reinforces my point, which is that Debian, in its present form, will find use primarily among technically adept users, which are a minority in the computer market. The same goes for its adoption at large IT companies. The fact that Debian is taking web server market share from Red Hat does not indicate that it is making any inroads into becoming a usable desktop for average users. > > > > I'm arguing to consider the point of view of would-be Windows > > > > defectors. > > I don't believe the Debian project is not meant to be a Windows > replacement. I don't even think it exists to compete with MS > Windows, but to provide a free(dom) operating system for everyone. It may be free for everyone, but they can't use it. You can, I can, but the average Windows user can't. That's like saying that anyone is free to buy a Mercedes, all you need is the money. > > Here are a couple of cases for things that casual users can > > manage in Windows PC's but would have great difficulty in Debian. > > The following is not meant to say that Windows is good. It's > > not: it's crap. But they did do some things right, and we ought > > to take notice. > > You can get books that help. In fact, the Debian GNU/Linux 3.1 > Bible (ISBN 0-7645-7644-5) is a great book for those just getting > started with Debian and Linux and answers the first two common > tasks they'd need to know as well as installation help and getting > a desktop up and running. They also discuss Internet and Intranet > services such as web servers, printing, file servers, FTP, etc, and > it's only $40.00 (hey, you're not paying for the operating system!) I don't need books like that because I can read the documentation. The average Windows user is not going to read it. They don't need to read books to fire up their Windows boxen, and they don't expect to read books to move to Linux. If it were up to snuff, they wouldn't need to. You're preaching to the choir by telling me that a technically adept person can make Debian do most common tasks without inordinate difficulty. The average computer user, OTOH, is a completely different story. > I just get a little upset when people want to mold Debian into > something like a Windows clone. If you want that, try a > Debian-derivative such as Linspire or Xandros. Linspire wants subscription money to keep it maintained. I don't know about Xandros. Ubuntu exists by the pleasure of a single individual. Knoppix is a live system and isn't meant for permanent disk installs. This request is not for me, it's for people who are stuck on Windows because they can't deal with a very old-fashioned and arcane command line interface. Computers for them are a tool, not a hobby and definitely not a way of life. They're not going to study manuals, memorize command arguments and the eclectic organization of the file system. How can we say we've made a free operating system for everyone, when less than 10% of the computer users are capable of running it? > I also don't like > it when people completely ignore the accomplishments of Microsoft > with Windows and rip them to shreds as if their operating system is > non-functional without considering that MS made the PC and an > office suite so prevalent. I don't agree with their business > tactics, licensing nightmares or their monopoly in the desktop > world though. They are outright predators, and their bloated code requires faster hardware every year just to break even. However, they have made an incredible contribution by making computers accessible to people who are not technically inclined. More than accessible, people (sometimes) enjoy using them. Building in that degree of user accommodation does not make something a Windows clone. It just makes it a better product. Especially if you can still drive it from a terminal to do things no one ever thought of. -- Seth Goodman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: Open Source Supported Graphics Cards
On Friday, August 11, 2006 6:23 PM -0500, Paul Johnson wrote: > On Friday 11 August 2006 14:41, Seth Goodman wrote: > > On Tuesday, August 08, 2006 6:43 PM -0500, Paul Johnson wrote: > > > On Tuesday 08 August 2006 10:38, Seth Goodman wrote: > > > > Since the end-users we need to interest, if we are ever to > > > > break out of the expert niche, will run X and use GUI's for > > > > everything, being limited to low-end 2D performance will be > > > > an ongoing problem. > > > > > > I thought the niche Debian was trying to fill was rock solid > > > stability and reliability in a 100% free software format. If > > > I'm confused, let me know. > > > > > > > > That's a reasonable goal, even a good goal, if you are willing to > > remain a small, exclusive club. If you believe that people who > > use Debian need to be comfortable with the command line, consider > > natural language as a second language behind PERL and be fluent > > in regexp's, then it will remain a terrific operating system for > > the few. Maybe this is what most people in Debian want. I'm > > relatively new here, so if that's the case, please educate me. > > It's not that hard if you use a desktop environment and use the > desktop environment task during installation. Getting it installed > is the tricky part, but you'll only have to do it once. And if you > don't like aptitude, there's kpackage, and I'm sure there's Gnome > frontends, and even a web frontend (if you're really brave or on a > trusted network). Me thinks you misunderstand. I didn't have any real problem installing a Debian server or desktop. OTOH, I don't panic when asked to grep for patterns, write a PERL script or (at least in the distant past) write SED scripts. However, casual computer users cannot and will not be able to do any of those things. Getting the desktop installed is only a small part of the battle for a typical Windows user moving to Linux. That step is probably the easiest for a computer noob, and the problems will start soon after. > > However, if you have a desire to bring quality, free software to > > a wider audience, you're not likely to get there with the present > > vision. For the majority of casual computer users, who are > > hostage to a certain evil corporation, the GUI is not just a > > convenience to be used after fully mastering command line > > operation. > > Though if you were read the HTML installation manual, or even just > the mastheads, you probably would have gotten a base install with > KDE installed without much problem. Of course I read the manuals before I did my first install. I'd give them a B+ for experienced computer users, and a D for casual computer users. They refer to all manner of things of which the casual user hasn't the faintest idea, and of the large number of concepts they don't understand, they are at a complete loss to figure out which are relevant. For example, we all understand what a kernel is, what it does and when you need to think about it, which isn't often. This is not realistic for the casual computer user. Frankly, even if we did successfully explain this in plain speak, I have no illusions that a casual user could manage to build a kernel to run on their non-compliant hardware. It's just not a reasonable expectation. For the experienced user, it's just another task, and any time spent refreshing what you've forgotten is time well-spent. In the Windows environment, hardware detection and driver installation is largely automatic. Knoppix approaches this level of hardware awareness, but Debian seems to lag in this area. > > We presently _require_ people who use Debian to do this, or they > > are effectively hamstrung once it's installed. > > Only if you aren't reading your monitor during installation is this > a problem. That only gets you to the end of installation. Besides, the average Windows user is not going to notice when hardware detection fails or there is a broken dependency because of the hundreds of lines of, to them, gibberish that scrolls by on the screen. We can watch this, they can't. Post installation, common tasks are not easily explained, and the documentation is often inconsistent or downright misleading. That's acceptable for experienced users. We have a sense when something doesn't sound right and will look elsewhere. When something works differently from the documentation, it's a challenge, not a brick wall. It all depends on your experience and point of view. I'm arguing to consider the point of view of would-be Windows defectors. > > Why do we require
RE: Open Source Supported Graphics Cards
On Tuesday, August 08, 2006 6:43 PM -0500, Paul Johnson wrote: > On Tuesday 08 August 2006 10:38, Seth Goodman wrote: > > Since the end-users we need to interest, if we are ever to break > > out of the expert niche, will run X and use GUI's for everything, > > being limited to low-end 2D performance will be an ongoing > > problem. > > I thought the niche Debian was trying to fill was rock solid > stability and reliability in a 100% free software format. If I'm > confused, let me know. That's a reasonable goal, even a good goal, if you are willing to remain a small, exclusive club. If you believe that people who use Debian need to be comfortable with the command line, consider natural language as a second language behind PERL and be fluent in regexp's, then it will remain a terrific operating system for the few. Maybe this is what most people in Debian want. I'm relatively new here, so if that's the case, please educate me. However, if you have a desire to bring quality, free software to a wider audience, you're not likely to get there with the present vision. For the majority of casual computer users, who are hostage to a certain evil corporation, the GUI is not just a convenience to be used after fully mastering command line operation. It is the _only_ way they are comfortable interacting with an operating system. If it can't be done through the GUI, it won't get done. Reading non-hyperlinked manuals and realizing that -a is different from -A, no less remembering which is which, is simply not in the cards for these folks. We presently _require_ people who use Debian to do this, or they are effectively hamstrung once it's installed. The software is free, if you are willing to devote a significant portion of your waking hours to learning the intricacies of an admittedly arcane system. Anyone is free to do that. That's fine if you're technically inclined. If not, you will find it very frustrating and consider it a waste of your time. People are generally loathe to do things they consider a waste of time, even if they have very little money, yet that's our price. Why do we require this? It's not for technical reasons, but because we believe it is _better_ for them as computer users. That might be true if we were mentoring young people studying computer science or electrical engineering. For non-technical users, it is an artificial barrier to entry into the world of open-source. And it's exactly that attitude, unless modified, that will keep Debian a great tool for a small group of sophisticated users, and unusable for everyone else. -- Seth Goodman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: Open Source Supported Graphics Cards
On Monday, August 07, 2006 7:33 AM -0500, [EMAIL PROTECTED] wrote: > I also heard that at that time the Intel chips were > available on motherboards, but not on plug-in cards. > > Has the situation changed? Not as far as I know. If they have made any PCI-E graphics chips, they have not yet achieved any market penetration. Integrated graphics motherboard chipsets use main memory for the video frame buffer and soak up main memory bandwidth. This was a bad idea when Apple first did it and it's still a bad idea today, but it _is_ cheap. That being said, integrated graphics motherboard chipsets do a reasonable job for many 2D applications. Still, a little bit of extra resources on the motherboard would be extremely cost-effective and you would then have little incentive to buy a separate graphics card, unless you were a hard-core gamer. Since most motherboard vendors also produce graphics cards that sell for more than the motherboard, you can see why this is not done. This creates a real problem for open-source projects, since nVidia and ATI graphics chips dominate the market for even mid-range graphics cards. Since the end-users we need to interest, if we are ever to break out of the expert niche, will run X and use GUI's for everything, being limited to low-end 2D performance will be an ongoing problem. -- Seth Goodman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: No kernel update yet?
On Friday, June 30, 2006 1:31 PM -0500, Joshua J. Kugler wrote: > Several days ago, DSA-1103 (2.6.8 kernel update) was announced due > to several security issues. But as of today, > http://www.debian.org/security/2006/ still does not show it, and > all my apt-get updates/upgrades have not downloaded it or indicated > that is is available. > > Is it coming? See http://lists.debian.org/debian-user/2006/06/msg02743.html -- Seth Goodman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: OT : need advice on bluebottle
On Wednesday, June 28, 2006 1:25 PM -0500, Kamaraju Kusumanchi wrote: > So finally, I am considering discarding the gmail's service and > getting a free account on bluebottle. Any advice in this regard is > highly appreciated. FWIW, I occasionally use gmail and have, but don't use much, a bluebottle address. The spam problem is better addressed with gmail if you use POP access to either of these providers and run a local spam filter. With a good Bayesian filter, you will have very few false positives. However, few != none, which is the root of the problem when you have a lot of spam. The best solution, IMHO, is to use a mailer that blocks as much spam as possible during the SMTP conversation. While a legitimate message will occasionally be blocked, the sender immediately receives a NDN and knows their message was not delivered. With my own business email usage, this has averaged less than once a year, and was easy to correct. Using well-chosen DNSBL's and other heuristics as a basis to refuse messages cuts down your spam load to the point that it is not difficult to manually view the titles of the few that are left. This means either finding a provider that rejects spam during the SMTP conversation or setting up your own MTA. Post-acceptance spam filtering works well only when there is not much spam to filter. I strongly agree that manually scanning a large spam folder every day is tiresome and error-prone. Rejecting messages at SMTP time, rather than accepting and silently dropping them (essentially what a large spam folder forces you to do), is the better way to go. As for CR systems like bluebottle's, I find those so annoying that I sometimes elect not to deal with them. That is why I turn off bluebottle's CR. If that account starts to receive a significant amount of spam, I will abandon it. Same for gmail and any other provider that fails to reject most spam during SMTP. -- Seth Goodman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: Sarge Kernel Image Package Question
On Thursday, June 29, 2006 1:55 PM -0500, Owen Heisler wrote: > So this isn't installed by default? No? Why not?! Because! On Thursday, June 29, 2006 1:09 PM -0500, Joey Hess wrote: > Ralph Katz wrote: > > I hope Etch will install the meta package by default. > > It does. Great news. Thank you. -- Seth Goodman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: Sarge Kernel Image Package Question
On Thursday, June 29, 2006 9:58 AM -0500, Ralph Katz wrote: > On 06/29/2006, Linas Žvirblis wrote: > > > Why should it? Many people prefer to manually choose their > > kernels, as this is not something you can upgrade at any given > > time. It is not a problem either way - installing or removing a > > meta package is not that hard, is it? > > Hi Linas, > > You are correct that installing the meta package is not hard. > > The issue is security; without the meta package, kernel updates are > /not/ automatic with apt-get/aptitude upgrades. For desktop users > and non-developers like me who maintain our own systems, it's easy > to miss the fact that kernel security updates are skipped without > the meta package. For this reason, I believe the current default > installation procedure and docs are flawed. > > But it seems I'm alone on this as my post to this list got no > response last April, > http://lists.debian.org/debian-user/2006/04/msg00547.html pasted > below. I agree with Ralph: this is a packaging problem that creates a security problem for the less expert users. While it is true that it's not hard to manually install the meta-package, here's the reason I believe it should be installed as the default. Compiling a new kernel, while not all that difficult, is not something the average desktop user typically does. It is also not something the average desktop user should be required to read about, or even deal with a dialog concerning pro's and con's during an install. This is likely to generate more confusion and unnecessary requests for help. Some Debian purists may consider this an opportunity to educate new users as to the options available, without regard to whether they want or need such information. I don't think it's unreasonable criterion that someone who just wants to create a Debian desktop install for the stable distribution should be able to go through the installation procedure and wind up with a system where _all_ security fixes are applied through the normal update tools. They shouldn't _have_ to read lots of manuals, and be confused by myriad options they don't understand, in order to achieve that result. They also should not have to go to Ubuntu, which exists at the whim of a single wealthy and well-intentioned individual. Making an exception for the kernel is getting it backwards. It's the experienced users that compile their own kernels, or use a kernel from other than the stable distribution, who should disable the automatic notifications in the update tools. In their case, even if they fail to get rid of the meta-package, they know enough to ignore any kernel update notifications they receive through apt-get update. Average desktop users, OTOH, don't even know they are missing a kernel security upgrade unless they read the fine print in the installation manual (assuming we add it) or subscribe to the Debian Security list. While in the ideal world, all users would do both of those things, most average desktop users will do neither. The punishment for that should not be a kernel with known security flaws. Nor should we erect barriers to average users who would otherwise be satisfied with a Debian system in favor of an unnamed commercial one. Retaining the requirement to manually add the kernel meta-package, if you want kernel security upgrades, is not a reasonable way to go, IMHO. Making it part of the default install, and adding a note in the install manual for advanced users as to when and how to disable it, makes a lot more sense. If we continue to insist on keeping things as they are, our place as an O/S with an 8% desktop share is quite secure. Demanding that users must educate themselves might feel righteous, but it won't attract new users. Does this approach "coddle" new users? Perhaps. Isn't that a bad idea? No, because Debian is just a tool, not a way of life. While there are many admirable social goals in the Debian project and the open-software movement, those are secondary for most users. They decide whether or not to use a given piece of software because of how much it improves their productivity and how much trouble it is. After using it for a while, _some_ of them will figure out that the reason it works as well as it does is because of the open-source development model, and will decide that's a valuable thing on it's own. That's all we need. -- Seth Goodman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: Replying to list
On Thursday, June 22, 2006 5:53 PM -0500, Steve Lamb wrote: > Seth Goodman wrote: > > I'd say it's quite a stretch to say that Elm is at the forefront > > of MUA technology. > > But who was talking elm? Last I checked we had references to > mutt and Thunderbird. Both of which do innovative things with mail > and both of which, admittedly, have serious warts. Here was the reference to my old friend Elm earlier in this thread: On Wednesday, June 21, 2006 8:21 AM -0500, Thibaut Paumard wrote: > <...> > I suppose the reason is: > http://www.unicom.com/pw/reply-to-harmful.html Here's the piece of that article that got me going: " Any reasonable, modern mailer provides this feature. I prefer the Elm mailer. It has separate "r)eply" and "g)roup-reply" commands. If I want to reply to the author of a message, I strike the "r" key. If I want to send a reply to the entire list, I hit "g" instead. Piece 'o cake. I mention Elm here (and a lot later on) simply because that's the mailer I use everyday. This sort of support is not unique to Elm Any reasonable mailer provides it. The Pine mailer, for instance, asks directly, "Reply to all recipients?" when you use the "r" command. It doesn't get much easier than that! " Having used Elm for many years, I feel a bit guilty bashing it. I don't think there's anything wrong with pointing out that it is outdated technology and hardly modern. While it's quite handy if all you have is a terminal screen to a server halfway across your continent, that's no longer the way most people run their desktops. Please, I didn't say no one, just that most use other means. That is particularly true for anyone operating a Winbloze desktop. Non-technical end users don't want to memorize keyboard combinations to drive their MUA. They also don't want to operate their word processors that way and often choose formatted text and HTML email when plain text would do. The horse left the barn on those issues long ago and we're not going to get her back in. If the keyboard shortcut control method was what people wanted, vi and WordPerfect would be the most popular combination around. Those were perfectly functional tools (still are). Though I will probably never forget vi commands 'till the day I die, I often use graphical text editors and word processors, just like today's noobs. I'm not even sure why. It's become a habit. My point is, one size doesn't fit all, and insisting on it won't win us many converts. If we want to see Linux usage increase to any significant degree, it is going to come out of the present pool of Win prisoners. While I can't deny that Mutt on 'doze would solve the list reply problem, most Win detainees either can't (because they have no control over what MUA they use) or choose not to use Mutt (because they don't like dealing with rc files). It's worth noting that Mutt is the MUA on a diminutive proportion of Win desktops. I'd go further to point out that anyone running Mutt on a Win desktop is sufficiently clued in that this discussion doesn't apply to them. Do we really want to erect a perceived barrier to entry into the Linux world? I don't think that's in anyone's best interest other than M$. --<== broken signature delimiter from brain-dead M$ MUA Seth Goodman Win prisoner #8974372 release date: unclear -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: Replying to list
. The fact remains that most people who read their mail on Windows workstations, as I do, _don't_ have a 'Reply to List' button. There are a lot more of them than 'nix systems. If you'd like to see that change, as I would, perhaps we could be a little more accommodating and take the operation of their MUA's into account when deciding how this list operates. We are just doing M$'s bidding when we make this mailing list cumbersome for Windows MUA's. This may be a club, but let's not make it an exclusive one. -- Seth Goodman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: i want spam
On Tuesday, March 21, 2006 10:59 AM -0600, Jon Dowland wrote: > At 1142755284, Hex Star wrote: > > Well by her signing up to this list and posting to it, > > since her address isn't obfuscated in the archives she's > > now one step closer to getting spam ;-) :P > > It's quite possible that a malicious third-party sent that > message in order to inconvenience the "real" Sara Baker... I no longer recall, but doesn't this list require that you respond to a confirmation email to prove that you control the address you are subscribing? -- Seth Goodman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: Azureus and the TCP port 6881
On Monday, February 06, 2006 6:30 AM -0600, Marcelo Chiapparini wrote: > my router, I guess, is with my IP provider... I can't do anything in > that machine... If you are behind a NAT router, that is the place that you have to forward ports. Ask your ISP how to log in to your router. Get a manual for the router online, if necessary. There is undoubtedly a configuration page for port forwarding. You want to forward the port that you select with the proper protocol (for Azureus that's both TCP and UDP) to the local IP of your machine. If the machine uses DHCP to get an IP, most routers will forward to the machine name. If it won't, you'll need to assign the machine a static IP to permit port forwarding. Since the way you do this is different for every router, I can't really give you anything more specific. Let us know how it works out. -- Seth Goodman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: Back to original topic [Was: [Poll: debian-newcomer list [Was: Re: newbies needing help for graphic login]]
> From: Andrei Popescu [mailto:[EMAIL PROTECTED] > Sent: Monday, January 09, 2006 8:35 PM <...> > 4. incorporate the hardware detection of derivative distros > (like Knoppix). This would probably be possible only for the > i386 branch (maybe also ia64/amd64?), but this branch is also > the one that will receive the most newbies. I would put a +1 on this, as it would help everyone, not just noobs. There is no reason for any distro to _not_ do the best job of hardware detection possible. -- Seth Goodman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: How to play these files on Debian (Sarge)
> From: Robert Glueck > Sent: Friday, December 30, 2005 1:46 PM <...> > You wanted some feedback on which media players play which > formats in Debian Sarge. I just ran a couple of tests on > my media players using common media formats. Here are the > results: > >mov avi wmv rm mpgmp3 > Xine yes yes yes no yesyes > VLC vid only yes yes no yesyes > Mplayer vid only yes yes no yesyes > RealPlayer no no no yes no yes > > With mov, MPlayer produced the error message "needs codec > for audio format 0x324D4451". Perhaps the same codec is > what's needed for VLC, too. I'll see if I can find it > somewhere. > > Versions installed: > > Xine 0.99.3 > MPlayer 1.0cvs > VLC 0.8.2-svn > RealPlayer 10.0.6.776 (Gold) for Linux Minor update to Bob's fine summary: VLC 0.8.4 plays .mov files with both audio and video (at least under Win2K, I assume the Linux version is the same) -- Seth Goodman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: RAR under linux: any alternative?
> From: John Hasler [mailto:[EMAIL PROTECTED] > Sent: Friday, December 16, 2005 11:58 AM <...> > I have no doubt that Debian contains hundreds of potential > infringements of IBM patents. That wouldn't surprise me. If someone violates your patent and you fail to defend it in any meaningful way, you are considered to have abandoned the patent and it becomes effectively void. Defending it can be as simple as sending an infringing party a letter demanding that they cease and desist from infringing on the patent. IANAL, but have some familiarity with the process because I have a number of patents. From the practical viewpoint, the fact that someone has legally abandoned their patent and would not prevail in court does not stop them from suing anyone. Patent suits are _extremely_ expensive, and unless you have very deep pockets, most organizations are compelled to settle even if there is no legal basis for the suit. Even if they _do_ have the resources to see it through and win, many companies will make a business decision to settle a patent suit that does not impact them in some horribly way on the advice of their lawyers. My non-lawyer understanding is that for all intents and purposes, if a patent is widely ignored and the patent owner neither warns the infringers nor initiates legal action against any of them, you are pretty safe doing what everyone else is doing. If the infringement is in "broad daylight", and not obscure and hidden, so much the better. -- Seth Goodman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: RAR under linux: any alternative?
> From: Carl Fink [mailto:[EMAIL PROTECTED] > Sent: Wednesday, December 14, 2005 7:21 PM > > > On Wed, Dec 14, 2005 at 02:34:31PM -0800, Steve Lamb wrote: > > > IIRC one of the algorithms that can be used in zip is > > lzw which is (or was) patented. > > The patent expired in 2003. > > http://www.sslug.dk/patent/lzwunisys.html In that case, it appears that using 7-zip to produce fixed-size, split zip files followed by generating a set of PAR files would accomplish the same thing as using RAR. That seems to answer Gabriel's question that started the thread, yes? The zip files each contain CRC's, so you can tell when one is bad and the PAR files allow you to repair defects. The two approaches are both the same: a message authentication code (hash, CRC or other MAC) to detect errors, followed by forward error correction to repair detected errors. You decide how much FEC you get by how many PAR files you generate. Same old - same old, except the compression and FEC are better than older methods. I also don't know if any other program besides 7-zip can put together the split archives it produces, since 7-zip can't put together split archives from WinZip. That's not much of an objection, since the program is free and the code is open for others to build implementations around. I haven't bothered doing split 7z or tar archives, yet, but the 7z archives are similar in size to RAR and have better MAC's. That makes the main advantage of RAR only that the PAR file generation is conveniently built-in. If a customer asks for RAR, I don't argue, so the fact that some people like it is also an advantage. -- Seth Goodman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: RAR under linux: any alternative?
> From: Seth Goodman [mailto:[EMAIL PROTECTED] > Sent: Wednesday, December 14, 2005 3:02 PM > > > I know this is a Debian list, but there is Windows tool called 7-zip There is a port of this tool in Debian unstable http://packages.debian.org/unstable/utils/p7zip so hopefully this at least provides another Debian-compatible method to read RAR's. The RAR decompression is in a non-free area of the developer's web site and I don't know what the license limitations are. They ported the command line 7-zip version, not the GUI-based tool, so it is scriptable. -- Seth Goodman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: RAR under linux: any alternative?
> From: Steve Lamb [mailto:[EMAIL PROTECTED] > Sent: Tuesday, December 13, 2005 11:49 AM > To: debian-user@lists.debian.org > Subject: Re: RAR under linux: any alternative? > > > Mike McCarty wrote: > > It is distributed with a BSD like license. IOW, you can > > redistribute, and source is available, but they retain > > rights. But no charge (unless you meant something > > different by the term "free"). > > Free of patent and royalty issues which ZIP is not entirely. :) I know this is a Debian list, but there is Windows tool called 7-zip that is distributed under the LGPL that can deal with zip, tar, gz and bz2. This makes me suspect that there cannot be any patent hindrances to the zip format itself. This tool, like RAR, can create a split archive with whatever size the user specifies. Zip files do have CRC's for each file they contain that are made at the time of file compression, and this is no different for RAR. Only the formats supported are different. It also has support for rpm, deb and cab files, and some support for decompressing RAR, but I haven't tried that. Since my Windows and Debian boxes are connected through SAMBA, I have no problem running the 7-zip tool on a Windows box and leaving the result on a Debian machine. Yes, this is both impure and heretical and I expect to be flamed all the way to the gates of hell for mentioning it. Like Mike, I am a practical person and use whatever tool I need to get a job done. While I prefer GPL'd tools for the same reason we all do, sometimes you have to use a closed source tool to accomplish a task. When a commercial software vendor recently asked me to provide him a particular large file in RAR format with PAR files, I didn't argue or attempt to "educate" him on the merits of GPL'd software, I just gave him what he needed. Same goes for what my clients request. Zealotry is bad for business. -- Seth Goodman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: "Antispam UOL" spam from [EMAIL PROTECTED]
> -Original Message- > From: Carl Fink [mailto:[EMAIL PROTECTED] > Sent: Saturday, November 19, 2005 2:55 PM > To: debian-user@lists.debian.org > Subject: Re: "Antispam UOL" spam from [EMAIL PROTECTED] > > > On Sat, Nov 19, 2005 at 01:48:28PM -0600, Seth Goodman wrote: > > > Losing a large part of their email connectivity might be the event > > necessary to encourage a competitor with more clue to come > > along and eat their lunch. > > Anyone else remember the Usenet Death Penalty? Or when backbone > provider AGIS was threatened within an inch of its existence for > hosting famed spammer Spamford Wallace and his many domains, > including the amazingly-arrogant ispam.net? (In fact, some > blame this matter for AGIS's end.) Just to be clear, I was in no way suggesting organized vigilante action as in your examples. My hope was that if enough individual mail systems decided to ban UOL traffic based on their own local policy, that something positive would likely result. Perhaps I did not make that clear. Stated another way, no matter what anyone else does or thinks, I don't have to accept UOL's mail and they don't have to accept mine. Because it's my mail system, I don't even need a reason. I do happen to have one, though nobody else has to agree or even listen to it. UOL operates a C/R system that emits lots of backscatter, and I consider that abuse of my network resources as well as those of the net in general. This bogs down my system and raises my connectivity costs. By rejecting their connection requests, I lessen the effects of both problems. Hopefully, if enough other systems made the same choice, UOL might decide to get some clue and fix their problem. Alternatively, another company may notice that UOL's conduct has created a business opportunity. I don't have a personal interest in how the problem is solved. If nobody else makes the choice I do, that's their absolute prerogative. Forming a mob and engaging in vigilante action is very dangerous, which is why it is illegal in many countries. Just as an angry mob of people is a threat to civil order, so is a vigilante action dangerous to the internet. Even if you happen to sympathize with the particular wrong that a vigilante action aims to correct, the process is so broken and dangerous that we should advocate strongly against it and avoid any temptation to participate. -- Seth Goodman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: "Antispam UOL" spam from [EMAIL PROTECTED]
> From: loos [mailto:[EMAIL PROTECTED] > Sent: Friday, November 18, 2005 8:25 PM <...> > Unfortunately, most of their clients are very happy with this > system: It is very effective for SPAM protection. > > In fact for non-list mail it is really a good idea: all you > correspondents have to respond the challenge one and only one time, > all subsequent mail is unchallenged. C/R systems are fundamentally broken as spam protection for the following simple reason: virtually all spam uses a forged return-path. The challenge message you send to a purported sender is itself spam, as that party never sent you a message and your challenge is unsolicited. In the absence of a means of return-path authentication, sending challenges to forged address is no different from anti-virus systems that send "virus notifications" to people who never sent them mail. This type of email abuse is collectively referred to as backscatter. SpamCop, for instance, treats backscatter exactly the same as spam and will list abusers for it. I completely agree with them. Many mail system maintainers feel the same way and will put MTA's that emit backscatter on local blacklists. While it might appear to the users of the C/R system that it is good because it reduces their spam load, they are probably unaware that their backscatter is part of the growing spam problem. All they're doing is shifting the burden to innocent third parties, and that kind of abuse deserves getting your MTA's blacklisted. While it's unreasonable to expect the average user to understand this, the ISP _certainly_ should understand this since they have to deal with everyone else's backscatter. They know how _exactly_ much it costs the recipients and they don't care because it is helping them. Knowingly abusing third parties in order to reduce your own costs is clearly abuse, and they deserve whatever each receiving system operator dishes out to them. > > You just can't use this account for list subscriptions. And you shouldn't turn on C/R at all, unless you don't care if you abuse innocent third parties whose addresses spammers decide to forge. > > Besides that they are one of the largest and most popular ISP here. And that makes a difference because ... ? Microsoft if very popular, yet they produce mostly crap. Popularity does not make something reasonable. I think it might help get the problem solved if more large organizations just put a block on their whole ASN. If that doesn't get their attention, then I don't want their mail anyway. Losing a large part of their email connectivity might be the event necessary to encourage a competitor with more clue to come along and eat their lunch. That's a win-win situation for former UOL users as well as former victims of UOL abuse. Of course, UOL gets a well-deserved loss. This is one kind of problem that competition is very good at solving. In the absence of competition, the users are stuck. That's why it's actually in your long-term interest for as many services as possible to ban UOL's mail. Though it is painful in the short run, if you attract more than one competitor, you may even get lower prices out of the deal. But the main thing is that you won't be part of the spam problem, and people will gladly accept your mail. -- Seth Goodman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: Request to remove Information
> From: Mike McCarty [mailto:[EMAIL PROTECTED] > Sent: Wednesday, November 16, 2005 2:58 PM <...> > How about the prejudice that software engineers are only good > for writing programs, while hardware engineers can design > both hardware *and* software? It just goes to show that knowledge may be finite, but ignorance is limitless. Hardware engineers like me can and do write software, it's just crude, inefficient, subject to abuse and not suitable for general distribution. It's good enough to test my own hardware, but a software engineer can do it in a third the time, so why bother? Similarly, I'm sure most software engineers can design hardware, but probably not something you would want to run through a production line and support in the field. I don't know where the idea came about that hardware engineers can write better embedded systems. For a software engineer to do a good job on an embedded project, they have to understand hardware, but that's very different from being able to do a manufacturable design. Similarly, a good hardware engineer has to know enough about software to intelligently talk to the software engineer, but that does not imply they could write the system. In the good situations, both engineers understand enough about each other's area that they can ask probing questions from a different viewpoint and come up with a better system design than either could have alone. I suspect that design managers who have the misguided notion you brought up have never worked with a real software engineer. This is not rocket science. If your pipes are leaking, don't call a carpenter. -- Seth Goodman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: Request to remove Information
the enterprise would be much greater. The reason this doesn't happen is that management is empowered to make financial decisions, technical staff is not and stockholders have not yet demanded it. It is essentially a failure of corporate governance. Management will not cut their own throats, even if it is better for the company. The inherent management bias that technologists are a commodity, along with their desire for self-preservation, has prevented our capitalist system from realizing the ultimate implementation of outsourcing. That is, the entire enterprise, especially management, would move to India or China. Only capital and the end market would come from the U.S., and not for long. In other countries, not only are salaries lower, but the ratio of the highest to the lowest paid employee is also significantly lower. Thus, companies in other countries are not nearly as top-heavy as those in the U.S. More resources go into work than administration compared to a similar-sized company in the U.S., so the companies are far more efficient economically. They also do not suffer as much the burden of perceived unfairness, so their employees are happier. Efficiency, measured by profits, is the holy grail of investors and economists alike. For society as a whole, that is not necessarily the sole factor that we choose to maximize. However, we have elected leaders who choose to maximize corporate profits above all else and we have no one to blame but ourselves. This explains such bone-headed initiatives as NAFTA, where we pretend there is a level playing field and allow market forces to sort things out. The playing field is far from level, and a biased market does a poor job of allocating resources. How do you take into account that some countries have strict environmental controls while others have practically none? Some countries subsidize housing and provide their citizens with health care, while others leave that entirely to the private sector. Some countries provide free post-secondary education to those who qualify, while others require students to pay their own way. Until we can come up with a system that takes these differences into account, pretending that we can engage in "free trade" is nothing more than a short-term gift to large corporations which we will all ultimately have to pay for. -- Seth Goodman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: Request to remove Information
rded in expectation of achievement, while technical personnel are rewarded only after demonstrated achievement." While my blood boiled, I paused to think, then asked why. He replied, "I guess it's harder to find good managers than good technical people." He honestly and sincerely said those words to my face. Believe me, I couldn't make up something that stupid if I tried. Please don't make the mistake of ignoring what we are dealing with. We can't fight this prejudice with our eyes closed. -- Seth Goodman > -Original Message- > From: Weissgerber, Tom L [mailto:[EMAIL PROTECTED] > Sent: Friday, November 11, 2005 10:43 AM > To: debian-user@lists.debian.org; Weissgerber, Tom L > Subject: Request to remove Information > > > Debian, > The following information should not have been made available > to the entire public domain. Please remove the following > links/files at your earliest convenience. > Date: Wed, 24 Sep 2003 10:57:42 -0700 > Message-id: > <[EMAIL PROTECTED]> > In-reply-to: > <[EMAIL PROTECTED]> > Message-id: <[EMAIL PROTECTED]> > Old-return-path: <[EMAIL PROTECTED]> > References: > <[EMAIL PROTECTED]> > Reply-to: [EMAIL PROTECTED] > > > Regards > > Tom Weissgerber > Intel Corporation > Validation Tool Development Manager > 916-356-5339 > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: Request to remove Information
> From: John Hasler [mailto:[EMAIL PROTECTED] > Sent: Saturday, November 12, 2005 5:18 PM > > > I wrote: > > It is legal in the US to hire only US nationals. > > Seth writes: > > It is illegal in the U.S. to discriminate on the basis of > > race, creed, national origin... > > You misconstrue "national origin". On can be simultaneously > a US national and of any "national origin" at all. I understand the distinction. While you can require any level of citizenship, you can't discriminate within that group. There are a large number of U.S. citizens and permanent residents who have national origins other than U.S., and we are not allowed to discriminate against them. That is not a small point. The U.S. does necessarily restrict immigration, as does every other developed nation. If we didn't, we wouldn't be arguing about outsourcing. All the technology jobs could easily be filled with qualified applicants from other countries who would work for a fraction of our wages and would happily emigrate here. None of the developed countries have an economy large enough to offer jobs to their own citizens plus every other human on the planet who wants one. That is a sad but relevant fact. Thus, excepting humanitarian disasters, you have to control immigration to a level that a given economy can absorb the new arrivals without creating undue hardship for those already present. Now, compare our situation with controlled immigration and strong laws against discrimination to the that in the third-world countries we are outsourcing jobs to. One could argue this is not an issue because not many U.S. residents currently want to emigrate to these countries. If they did, their job prospects, except for foreign corporations, would be slim to none. The reasons would be both national origin and race (call it culture if you want to be polite), and it wouldn't matter if you became a citizen. Such is the irony of the current situation. -- Seth Goodman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: Request to remove Information
> From: Michael Marsh [mailto:[EMAIL PROTECTED] > Sent: Saturday, November 12, 2005 4:50 PM <...> > What companies *can* easily do in the U.S. is to require that > applicants be either citizens or permanent residents. You can't force > an employer to pay for your visa. The "permanent resident" > requirement can put up a sizeable barrier. Many tech companies choose > to pay for employee visas because it either makes it easier to fill > the position or it allows them to hire people who, even with the cost > of the visa included, ask a low enough salary to keep average pay > levels down. Good point. Let's not forget that we annually grant somewhere around 140,000 H1-B visa for "guest workers" where employers certify that they can't hire a U.S. citizen or permanent resident for the job. This certification is normally bogus, as the unemployed engineers in California will attest. The Federal government takes the corporations' word regardless. These employees are truly at the mercy of their employer, without whom they will get a quick trip back to their country of origin. They do not complain about unsafe working conditions, excessive overtime or any other abuses and will work for much lower salaries than their U.S. counterparts. The company is required to certify that they are paying the same wages to the "guest worker" as their U.S. counterparts, but that is also widely known to be untrue. These visas only cost the hiring company around USD$500, so it is a tiny price to pay for a low-cost employee who will not dare complain about anything. There is also the L1 visa program, where an multinational can transfer an "employee" from a branch in another country to their U.S. operations. The non-U.S. employee often turns out to be a temporary hire, often from a subcontractor who provides temporary workers, then sent to the U.S. to work for below market wages. As this is a "transfer" within the company, there is no need to make any certification about the wages paid or the availability of U.S. workers for the job. Recent legislation that would have raised the cost of the L1 to USD$1500 was recently rejected, so this is cheap and easily abused. I believe the number of L1 workers in the U.S. is around 50,000 annually. The end result of outsourcing coupled with abuse of the H1-B and L1 visa programs is to lower the wages of technology workers in the U.S. In this respect, it has been successful. In its biennial salary survey, the IEEE reports that the median wage of U.S. engineers has gone down in real dollars for the first time in the 30 years the IEEE has conducted the survey. IMHO, we are just at the beginning of the decline. Already, manufacturing firms who make electronic hardware in China are finding that prices are rising there and are considering moving production to lower cost places, such as Africa. There is always someone who is hungrier. -- Seth Goodman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: Request to remove Information
> From: John Hasler [mailto:[EMAIL PROTECTED] > Sent: Saturday, November 12, 2005 3:38 PM > > > Seth writes: > > They have a sense of national pride and feel a part of the Indian > > economy, thus they naturally prefer to hire their own > nationals. That's > > illegal here... > > It is legal in the US to hire only US nationals. It is illegal in the U.S. to discriminate on the basis of race, creed, national origin and numerous other factors in hiring. There are exceptions where a job requires a security clearance and there are probably other exceptions I am unaware of. Most jobs, however, are subject to the laws against discrimination. As we are all well aware, most companies do _not_ discriminate based on national origin in their hiring decisions because aside from it being illegal, there are large civil remedies. Discrimination lawsuits are horribly expensive and often successful. Even where I live, in the mid-Western U.S., most technology companies have engineers on their staff who were born in other countries. Look at the engineering staff at most technology firms in "the valley" (California, for the non-U.S. readers) and you will clearly see that hiring decisions have little to do with national origin. A significant number of U.S. technology companies have CEO's who were not born in the U.S. While there is still discrimination in the U.S., engineering positions are, thankfully, no longer a big part of that problem. -- Seth Goodman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: Request to remove Information
> From: Weissgerber, Tom L [mailto:[EMAIL PROTECTED] > Sent: Friday, November 11, 2005 10:43 AM > To: debian-user@lists.debian.org; Weissgerber, Tom L > Subject: Request to remove Information > > > Debian, > The following information should not have been made available > to the entire public domain. Please remove the following > links/files at your earliest convenience. > Date: Wed, 24 Sep 2003 10:57:42 -0700 > Message-id: > <[EMAIL PROTECTED]> > In-reply-to: > <[EMAIL PROTECTED]> > Message-id: <[EMAIL PROTECTED]> > Old-return-path: <[EMAIL PROTECTED]> > References: > <[EMAIL PROTECTED]> > Reply-to: [EMAIL PROTECTED] > > > Regards > > Tom Weissgerber > Intel Corporation > Validation Tool Development Manager > 916-356-5339 > This is both funny and tragic at the same time. You post a private memo that puts your employer in a very bad light to a high-traffic public mailing list. In case anyone might wonder what you could do to top something that dumb, you satisfy their curiosity by making a second post to the same list requesting the first post be removed from the archives. I understand that it is a little hard to talk with both feet in your mouth, but maybe you could take one foot out for long enough to explain your bizarre request? What's interesting about this is why would Intel, as a company, be concerned with removing a two-year-old memo from the public record? Was Intel truly unaware in 2003 of the massive unpopularity of such greedy behavior? Do they really think that by removing such small pieces from the public record that they can deny their involvement with the massive outsourcing binge of which their technology center in Bangalore was at the forefront? This is really curious. Assuming this is something like their motive, why would they send the same fool who did the damage in the first place? Thank you, Tom, for being who you are. Without your help, we might never have thought about this incident again. -- Seth Goodman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: Request to remove Information
> From: Weissgerber, Tom L [mailto:[EMAIL PROTECTED] > Sent: Friday, November 11, 2005 10:43 AM > > > Debian, > The following information should not have been made available > to the entire public domain. Please remove the following > links/files at your earliest convenience. > Date: Wed, 24 Sep 2003 10:57:42 -0700 > Message-id: > <[EMAIL PROTECTED]> > In-reply-to: > <[EMAIL PROTECTED]> > Message-id: <[EMAIL PROTECTED]> > Old-return-path: <[EMAIL PROTECTED]> > References: > <[EMAIL PROTECTED]> > Reply-to: [EMAIL PROTECTED] Well, Tom, wake up and smell the coffee, and thanks for the heads up! I own an embedded hardware systems design company that also does PC board layout. I am obviously delighted to see that Intel, in this time of economic hardship, is outsourcing badly needed technical work to places with low labor costs and few, if any, meaningful labor or environmental laws. Perhaps you should consider that your entire system validation tool section, including your position, could easily be outsourced. In fact, I hope it is! Don't worry, they would never hire you for your current job, even if you showed up in India and offered to work below the local wage. Are you curious why? They have a sense of national pride and feel a part of the Indian economy, thus they naturally prefer to hire their own nationals. That's illegal here, but thankfully, they are not so constrained. In addition, you have no caste and are thus automatically excluded from most middle-class jobs. Or didn't you bother to check out the local apartheid? I will make it a point to view the use of Intel processors, Ethernet MAC/PHY's and other products in upcoming designs from a more informed point of view. Thank you for opening my eyes. -- Seth Goodman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: Is Debian ready for the desktop?
> From: John Hasler [mailto:[EMAIL PROTECTED] > Sent: Saturday, November 12, 2005 12:19 PM <...> > SCO changed its name to Tarantella and was recently acquired by Sun. So does that mean an end to their BS legal actions? -- Seth Goodman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: Responses to the list (oops)
> From: Steve Lamb [mailto:[EMAIL PROTECTED] > Sent: Monday, September 26, 2005 2:50 AM > > > Seth Goodman wrote: > > Referencing 822 for much of anything these days is not very > > useful, unless > > if you're interested in email history. > > Which is something you need to know when blatently getting > 822 and 2822 backwards when it comes to reply-to. I am well aware of the differences between the two standards. You would do well to read them both carefully as well as RFC1123. > > > As I pointed out in a previous post, > > Reply-To: is an optional header that is set by the _sender_ of > the message. > > Incorrect. Have you even read RFC2822? I decided to refresh > my memory and reread it and it took me all of 30s to debunk this > notion. I've spent more hours studying that and related standards than I care to think about. Your 30 second peek has produced laughable results and the insults alone are reason to kill-file your posts. However, others on the list may be interested as why your conclusions are incorrect. > > - > > 3.6.2. Originator fields > >The originator fields of a message consist of the from field, the >sender field (when applicable), and optionally the reply-to field. > > - > > Not the sender of the message, or ORIGINATOR of the message. The From:, Sender: and Reply-To: have historically been called originator fields. You have chosen to strictly interpret that term, out of context, as the original author. Unfortunately, it doesn't mean that at all. When an original author sends a message to a recipient, the author and originator happen to be the same, but there are a number of other cases where the author and originator are different. Among these are mailing lists, end user resending and submission on behalf of another party. In RFC2821/2822, as well as 1123, originator means the party submitting a message for transmission through an originating gateway MTA to a destination gateway MTA for delivery to one or more mailboxes. A mailing list operates according to a redistribution model which is distinct from list exploding, alias forwarding, or end user encapsulation forwarding. It is related to, but distinct from, end user resending. Here is the relevant citation from RFC2821: |3.10.2 List | | A mailing list may be said to operate by "redistribution" rather than | by "forwarding". To expand a list, the recipient mailer replaces the | pseudo-mailbox address in the envelope with all of the expanded | addresses. The return address in the envelope is changed so that all | error messages generated by the final deliveries will be returned to | a list administrator, not to the message originator, who generally | has no control over the contents of the list and will typically find | error messages annoying. Redistribution means that the list MX first accepts a message, which is then considered to have achieved final delivery. The life of that message, as far as SMTP is concerned, is now _over_. The list then creates a _new_ message, which it _reinjects_ into the message stream to a new list of recipients. As far as SMTP is concerned, this is a completely new message and the list is the originator. This has nothing to do with authorship, it has to do with message submission into a transport environment. In the redistribution case, the only prohibition for 2822 headers is that the list MUST NOT change the From: header. The Reply-To: header is optional in the first place, and as the new originator, the list is free to do what it wants with it. To show that the list is resending the message, rather than just forwarding it, most lists set the Sender: header to the list address. Thus, there are two headers, MAIL FROM: in the envelope and Sender: in the body where the list explicitly claims to be originator. > Since the message isn't the originator it doesn't get to touch those. See the above. You don't seem to understand the concept of message origination. > The exception, as noted, is sender. No, it's part and parcel of the whole framework, not an exception. This is just one of the cases where author and originator are not the same. When a party submits a message for transmission on behalf of another party, the original author is listed in From: and the party submitting the message for transmission MUST list their address in Sender:. Another use of Sender: is if there are more than one original authors listed in From:, in which case Sender: is also REQUIRED, since only one individual or system submits a given message. Again, note that the message originator is the party listed in Sender:, not the original author listed in From:. The Date:, Message-ID: and first Received: header all correspond to the submission of the message, not when it was authored. As
RE: Responses to the list (oops)
> From: Steve Lamb [mailto:[EMAIL PROTECTED] > Sent: Saturday, September 24, 2005 2:41 PM > > > Seth Goodman wrote: > > Getting back to the reply function, the standards are silent as > > to how to > > treat Reply-To: for a redistributed message and the field is optional to > > start with. The preferred reply action for a mailing list message is to > > reply to the list (the actual sender of the message you received) rather > > than the original poster (a private reply to a public post, not > > generally > > appropriate). It is perfectly within the purview of the list > > to alter the > > Reply-To: header so that the most commonly deployed MUA's will > > perform the > > preferred action when the recipient hits reply. > > Wrong, wrong, wrong. How you can cite 2822 as a reference for reply-to > munging while denouncing 822 is beyond me. It was 822 that had an explicit > reference to mailing lists as an acceptable use of 822. 2822 *removed* that > reference on reply-tos just because of the long-standing debate over > reply-to munging. Referencing 822 for much of anything these days is not very useful, unless if you're interested in email history. As I pointed out in a previous post, Reply-To: is an optional header that is set by the _sender_ of the message. When you receive a message that was redistributed by a mailing list, the _list_ is the current sender. That is why the list MUST replace the original return-path with theirs. The logic behind this is that the poster has no interest in receiving DSN's resulting from the subsequent redistribution of their message. That is for the list to keep track of. Similarly, being a mailing list and not a private conversation, it is both inappropriate and cumbersome for the original poster to answer a public post with a private reply. The purpose for a public mailing list is to have a public conversation, with one answer hopefully satisfying many readers with the same question. Taking into account how the vast majority of deployed MUA's operate, it is perfectly reasonable, and not in conflict with the RFC's, for a mailing list to change Reply-To: in order to have the reply button do the desired action in the majority of cases. Now, you can insist that the majority of the mailing lists have it dead wrong, as do the majority of deployed MUA's around the internet. If that's your position, go ahead, you're arguing with a de facto standard that is incredibly widely deployed. Your opinion, as well as mine and that of RFC2822 are quite irrelevant in this respect. There are millions of deployed MUA's and tens of thousands of mailing lists that already operate in a particular way. In fact, most users of those systems _like_ the way they operate. The chances of changing all that infrastructure, that users actually like, is between slim and none. After all that work, the payoff would be what? Only that mailing lists and MUA's would operate the way _you_ think they should. Nothing practical will have been gained. That is commonly know as a waste. Believe me, we've got _much_ bigger fish to fry in terms of MUA's and email practices, and this one doesn't make it to the short list. As an example of another de facto standard, consider the Sendmail interface. It is not great by today's standards, but people got very used to it when it was the only game in town. Looking at Exim, the default MTA for Debian, there are a large number of options that they went out of their way to provide so that people used to the Sendmail interface could easily adopt Exim. They were rewarded for this foresight by rapidly garnering a reasonable share of MTA deployments. They could have insisted that conforming to an outdated interface was a waste of effort and technically questionable. Had they taken that approach, they might have the satisfaction of having it their way but it probably wouldn't be the Debian default MTA. It's perfectly reasonable to argue technical merit in technical committees and in engineering departments, but when it comes to de facto standards, you can either recognize them or become a footnote in technical development. > > The real question is why List-Post was written in such a way as so > that people could debate it's usefulness as an inidicator of where to > send replies (it has happened, believe me) and why the head-honchos up > on high who debate such standards have gone on record as saying that a > list-reply is not needed. The answer is simple, it _isn't_ needed for any practical purpose. There is already a reply header that the list is allowed to use, and in fact most lists _do_ use. There is no purpose for an additional header that the great majority of deployed MUA's don't use anyway. Anyone who proposes a solution to an
RE: exim4-light vs exim4-heavy
> From: Dave Ewart [mailto:[EMAIL PROTECTED] > Sent: Sunday, September 25, 2005 10:18 AM <...> > Well, yes: but that applies regardless of whether you've launching it > from procmail or not :-) Well, not exactly. I don't know enough about Exim to know if it can operate this way, but if you do your AV/content filtering during the SMTP transaction, you can reject with a 550 at the end of data. That is a lot better than silently discarding messages after accepting them. Yes, that keeps the TCP connection open a long time, but for a small to medium sized system, that should not be a big issue. The real savings is in rejecting before data based on a variety of measures, terminating the connection much sooner and saving a lot of bandwidth. If you do enough of that, you can cut down the number of messages that you allow to go into data, and thus require AV/content filtering, to the point that it is much less of a load on the system. -- Seth Goodman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: Installing without CD
I think what James was trying to say is that both your time and the time of those offering advice is probably worth a good deal more than the cost of a new CD burner. I don't think he meant any insult, so please don't take it as one. You'll probably want one for backups, anyway, so it's not a wasted expense. --Seth Goodman -Original Message-From: Mike S [mailto:[EMAIL PROTECTED]Sent: Sunday, September 25, 2005 8:00 AMTo: debian-user@lists.debian.orgSubject: Re: Installing without CDNo comment. On 9/24/05, James Sweet <[EMAIL PROTECTED]> wrote: >My CD burner doesn't work.I'd recommend buying a new burner, or a good used one, they're dirt cheap.If that's too expensive then obviously your time is worth a lot less thanmost people's, either that or you like frustration.
RE: unable to install from CD: failure to mount once kernel installed
> From: Seth Goodman [mailto:[EMAIL PROTECTED] > Sent: Friday, September 23, 2005 4:45 PM <...> > eject is not there, nor are its man pages. I installed the eject package > and now "eject -r" works, as does the gnome eject command! Looks > like this is a third bug to report Wrong! My bad. This is the cause of the GUI error, so there are only two bugs involved. -- Seth Goodman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: Responses to the list
> From: [EMAIL PROTECTED] On Behalf Of Antony Gelberg > Sent: Friday, September 23, 2005 12:11 PM <...> > Another option for those who don't like the list policy is to become > Debian Developers and change the policy. What an appealing offer. In other words, non-developers need not express their opinions here. But wait, I thought the title of this list was debian-user? How very foolish of me, I had no idea I was on a developer's list. Sorry for wasting your valuable time, and mine. Now if I'm mistaken and this list really is for debian users, then you are certainly aware that your suggestion is insulting to any non-developers. Why would you want to do that? -- Seth Goodman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: unable to install from CD: failure to mount once kernel installed
> From: Mike McCarty [mailto:[EMAIL PROTECTED] > Sent: Friday, September 23, 2005 3:26 PM <...> > It looks like either you don't have eject installed, it is installed in > the wrong place, your PATH is incorrect, or Gnome is pointing to the > wrong place. What happens if you insert a CDROM into the drive, close > all windows accessing it, and do > > $ umount /media/cdrom (or /mnt/cdrom, or wherever you mount it) > $ eject -r > > in a terminal? eject is not there, nor are its man pages. I installed the eject package and now "eject -r" works, as does the gnome eject command! Looks like this is a third bug to report: missing dependency in gnome installation (or would you call it something else?). Thanks, Mike and Wackojacko for all the help. The last thing I need to make this a permanent workaround is the proper init script in which to put the "hdparm -d0 /dev/hdc" call so it happens on every reboot. It needs to run with root privileges. Alternatively, is there a configuration file somewhere, that I have not been able to locate in the Debian reference, the Debian website or the man pages, that would allow me to disable DMA on that drive without an explicit call to hdparm? -- Seth Goodman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: Responses to the list (oops)
> From: Ron Johnson [mailto:[EMAIL PROTECTED] > Sent: Friday, September 23, 2005 12:50 PM <...> > http://www.unicom.com/pw/reply-to-harmful.html This is written from the perspective of Elm being the reference for all MUA's. Though I used Elm twenty years ago as my primary MUA, the MUA's in widest use today do _not_ have reply-to-list functionality and use the Reply-to: header to direct the reply to the proper address. This fellow's citations are as outdated as his MUA. RFC822 was published in 1982 and RFC1123 updated it in 1989. So much has changed since those standards were published that most people involved in email consider RFC2821/2822, published in 2001, to be far more relevant, even though those are still officially classified as proposed standards (the IETF sometimes moves at the speed of a glacier). Looking at RFC2822, section 3.6.2: 3.6.2. Originator fields <...> The originator fields also provide the information required when replying to a message. When the "Reply-To:" field is present, it indicates the mailbox(es) to which the author of the message suggests that replies be sent. In the absence of the "Reply-To:" field, replies SHOULD by default be sent to the mailbox(es) specified in the "From:" field unless otherwise specified by the person composing the reply. Now, RFC2821 clearly defines mailing lists as operating on a "redistribution" model, where the list is considered the new sender. The list MUST change the return-path (argument of the MAIL TO: command) to the list owner (though common practice uses a VERP address instead) and the original From: header MUST NOT be altered so as to retain the original author. Most mailing lists, though not all, choose to set the Sender: header to the list owner to show that the mail did not come directly from the original author, but was a bulk redistribution (re-injected into the internet mail stream) by the list on the author's behalf. While the RFC's don't require this, other sections in RFC2822 give the basis for this practice. Though the Resent-From: header might have been a better choice, most sites chose Sender: instead. Getting back to the reply function, the standards are silent as to how to treat Reply-To: for a redistributed message and the field is optional to start with. The preferred reply action for a mailing list message is to reply to the list (the actual sender of the message you received) rather than the original poster (a private reply to a public post, not generally appropriate). It is perfectly within the purview of the list to alter the Reply-To: header so that the most commonly deployed MUA's will perform the preferred action when the recipient hits reply. In short, you need a good reason _not_ to do something the same way as the rest of the world when it comes to email. The site referred to above does not make a compelling case given today's normal practices. -- Seth Goodman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: unable to install from CD: failure to mount once kernel installed
> From: Wackojacko [mailto:[EMAIL PROTECTED] > Sent: Friday, September 23, 2005 5:56 AM <...> > Googling this error (google is always your friend :) ) suggested that > > - you may want to turn DMA off for the drive ' hdparm -d0 /dev/hdc'. > May need to install 'hdparm' first. Ah, thanks for both the suggestion and the method. Mike McCarty privately suggested that I disable DMA for this drive, but I couldn't do it from BIOS and was unaware of this system utility. Thank you very much for bearing with me. This seems to fix the problem! It also uncovered another minor bug, but at least the system is usable. After disabling DMA on the CDROM, inserting a CD causes the file system to mount, a CD icon to appear on the gnome desktop and a Nautilus file browser opens showing the CD file system. To unmount the file system and unlock the CDROM eject button, close the file browser, right click on the CD desktop icon and hit eject. At that point, I get an error dialog that reports: Failed to start command (details: Failed to execute child process "eject" (No such file or directory)). However, the CD icon does then disappear from the desktop and the CDROM tray eject button becomes unlocked, so it did the job despite the error message. Directly unmounting the CD file system as root using umount /media/cdrom0 accomplishes the task without any error messages, though you shouldn't have to do this. So it appears that I have two bugs to report, one for the driver not being able to operate the drive with DMA enabled and another for the GUI error, though I am not certain what packages to report them under. Googling a bit further, as you suggested, shows that failure to mount CD's is not a new problem in Linux and some people have unsuccessfully tried to fix the root causes. I hope they are still trying. See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=137831 This user had the same problem with both FC3 and FC4 and with certain builds, the problem was intermittent. Follow-up reports showed that it was a nasty interaction between haldaemon, DMA and the kernel itself. It was not fixed in the 2.6.12-1.1398_FC4 kernel, though they expected it to be. The root cause is thought to be some piece of code looking for information at the very end of a CD that is at a different location when the CD is not completely full. The DMA hangs waiting for the nonexistent data and things go downhill from there. The Fedora crew still hasn't solved this one, suggesting it is more complicated than that. I haven't figured out if it is limited to Joliet, Rock Ridge or plain ISO9660. The media I used were all Joliet and I don't believe that I have any other types around to try. Both CD writers that I own are on Windows machines, and they always write with Joliet format extensions. I would like to report the fact that the CDROM driver malfunctions with DMA enabled to the Debian bug tracker, and the eject GUI error as a separate bug, but I'm not sure what packages to list. After reading the Fedora discussion on this problem, it's not clear that anyone really knows which packages are at fault. I also wonder how to make this change permanent. I could put a call to hdparm in one of the init scripts, though I was hoping that /etc/fstab or some other configuration file might have a "nodma" option to set for that drive. I cannot find such an option in either the Debian reference or the man pages for fstab, mount, etc. I'm sure it exists somewhere, but I haven't been able to find it. The Debian reference shows a command called setcd in section 9.1.3, but it looks like it's meant for setting the default speed. The package page on setcd has no information on what it does. > > - hal (hardware extraction layer) deamon can cause this trouble so try > stopping haldeamon if installed. I didn't try this, but I bet it would work. It's not as good a workaround, though, as you would want to start it again each time you were done reading a CD. -- Seth Goodman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: NUM Lock , Home, End
> From: Marty [mailto:[EMAIL PROTECTED] > Sent: Thursday, September 22, 2005 6:47 PM <...> > Sounds like a good reason to file a wishlist bug report. I'd be happy to do so. Where do I file this type of feature request, and do I need to know the name of the package to do it? -- Seth Goodman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
