Date: Tue, 11 Dec 2007 21:05:42 +0100
From: "Mirco Piccin" <pictux@gmail.com>
To: "Amit Uttamchandani" <atu13439@csun.edu>
Cc: debian-user <debian-user@lists.debian.org>
Subject: Re: Replacing HD with Flash IDE drive
Message-ID: <ff8e9dfe0712111205s4fa4fc55y64a881804f4bdb20@mail.gmail.com>
Content-Type: multipart/alternative;
boundary="----=_Part_10114_3831651.1197403542171"
------=_Part_10114_3831651.1197403542171
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Hi!
> Anyways, flash based IDE drive would be the solution I am guessing. I am
not really concerned with the size as I am running a fairly
> minimal debian system. So about 4G would be perfect.
>
> So anybody has any experiences with this on Debian? Does the Flash HD
simply look like an IDE drive in debian?
Yes, i've done the same for my home "server".
It's based on a fanless miniitx, and the only noise was the HD.
I use a CF 2 IDE adaptor; CF is recognize as IDE hd and the installation was
done with no problems.
And until now no problems, of course.
Also i use a 4 gb cf.
Only, i don't know if there an adaptor from PowerBook g4 hd connector (sata?
eide?) to cf.
Hope this encourage you!
Bye
------=_Part_10114_3831651.1197403542171
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Hi!<br><br>> Anyways, flash based IDE drive would be the solution I am guessing. I
am not really concerned with the size as I am running a fairly<br>> minimal
debian system. So about 4G would be perfect.<br>> <br>> So anybody has any experiences with this on Debian? Does the Flash HD simply look like an IDE drive in debian?<br><br>Yes, i've done the same for my home "server".
<br>It's based on a fanless miniitx, and the only noise was the HD.<br><br>I use a CF 2 IDE adaptor; CF is recognize as IDE hd and the installation was done with no problems.<br>And until now no problems, of course.<br>
<br>Also i use a 4 gb cf.<br><br>Only, i don't know if there an adaptor from PowerBook g4 hd connector (sata? eide?) to cf.<br>Hope this encourage you!<br><br>Bye <br>
------=_Part_10114_3831651.1197403542171--
Date: Tue, 11 Dec 2007 09:43:37 -0800
From: Bob McGowan <bob_mcgowan@symantec.com>
To: debian-user@lists.debian.org
Subject: Re: buying TV card: somewhat OT
Message-ID: <475ECC49.6060903@symantec.com>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070903020609090507040502"
This is a cryptographically signed message in MIME format.
--------------ms070903020609090507040502
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Andrew Sackville-West wrote:
> On Mon, Dec 10, 2007 at 03:52:10PM -0800, Bob McGowan wrote:
>> Andrew Sackville-West wrote:
>>> On Wed, Nov 28, 2007 at 08:43:38AM -0500, Scott Lair wrote:
>> ---deleted---
>>> so its not strictly etch. Also, these cards include hardware mpeg
>>> encoding which can be a blessing and a curse, depending on your
>>> situation.
>>> A
>> Could you expand a bit on the subject of "a blessing and a curse" with
>> respect to hardware mpeg encoding?
>
> It's a blessing because having the mpeg encoding performed in hardware
> on the card takes the load off your cpu. You can process more streams
> with less cpu. It's a curse because the streams are compressed before
> you get access to them. Any additional processing you might do will be
> done on data that has already been compressed, leading to degraded
> quality.
I was under the impression that, even with CPU based encoding, the
recording process went directly to the compressed format.
Does what you say mean that the uncompressed data stream can be stored
and edited later? I realize this would mean huge files but it would
lead to higher quality final copies, as you say.
Or is it a matter of applying "filtering" in the data pipeline?
>
> ymmv.
>
>> Or, point to a relevant discussion of the issue?
>
> well, we're having one right now ;-)
>
>> I've been holding out, waiting for hardware mpeg card support in MythTV
>> (been a while since I've checked, looks like it may have improved since)
>> and was not aware of negative issues with it.
>
> The hardware mpeg support is not in MythTV directly but is in the
> drivers for the particular cards. Many of the Hauppage PVR cards (I
> have two) have been supported by ivtv drivers for at least a couple of
> years. You should be looking for kernel support for the cards, not
> mythtv support. If there is kernel support, then there will be
> /dev/video* devices that mythtv can record from.
>
> A
Thanks, very helpful.
--
Bob McGowan
Symantec, Inc.
--------------ms070903020609090507040502
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJHzCC
AuowggJToAMCAQICECmQqFDEfU4fi2p+cKn5lqcwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE
BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT
I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDkxMTAwMDU1MFoX
DTA4MDkxMDAwMDU1MFowSjEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEnMCUG
CSqGSIb3DQEJARYYYm9iX21jZ293YW5Ac3ltYW50ZWMuY29tMIIBIjANBgkqhkiG9w0BAQEF
AAOCAQ8AMIIBCgKCAQEAq/lfgQSbtSgweKsPWnz5XleG3Axjk+f4VZzghtUaHXJXyA4Fj3pV
nxDJWbiZxIQrOVCFHOi/WEADwzVr7QxTfYTVx88mB+1QygGQDJIcwHXg3Wp0Z5sGDd7hCUaA
8AZ+JbMECplyJorgfvCU1ydrLusPbiJ/JlgsjcAx+Wcxqxsp9F6+68nQmp33Q34TfMoN9NZl
x1X6UgE+Hp/C769+eAN97iXE0tVI2ZPW8D4YicWJzE/G7WdNFZGUfca7D7C0mxq1OBGMObog
a9qAThfnY5DGrcFn8zFslIfW2Vv3cyYe6PupkPJrMqjP5zfjfgXK8jDA+Wflam59NXBx8AiP
xwIDAQABozUwMzAjBgNVHREEHDAagRhib2JfbWNnb3dhbkBzeW1hbnRlYy5jb20wDAYDVR0T
AQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQAafvlXVTPVMkFJvO0Y5KIZu2RINMz1giH+nV8y
Utypjj8+SpizR1w5dBwFBM1NJ9Of9PofklRli98n5Amu3uUdVUz0GXPvvwV5T2i5InmOQhdv
n65sBTHcErFesk5IEI8HasCGlJLZZ3WpWAKCiQF7pJ5aBBpWOz9JhN1wjOEYbTCCAuowggJT
oAMCAQICECmQqFDEfU4fi2p+cKn5lqcwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx
JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0
ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDkxMTAwMDU1MFoXDTA4MDkx
MDAwMDU1MFowSjEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEnMCUGCSqGSIb3
DQEJARYYYm9iX21jZ293YW5Ac3ltYW50ZWMuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A
MIIBCgKCAQEAq/lfgQSbtSgweKsPWnz5XleG3Axjk+f4VZzghtUaHXJXyA4Fj3pVnxDJWbiZ
xIQrOVCFHOi/WEADwzVr7QxTfYTVx88mB+1QygGQDJIcwHXg3Wp0Z5sGDd7hCUaA8AZ+JbME
CplyJorgfvCU1ydrLusPbiJ/JlgsjcAx+Wcxqxsp9F6+68nQmp33Q34TfMoN9NZlx1X6UgE+
Hp/C769+eAN97iXE0tVI2ZPW8D4YicWJzE/G7WdNFZGUfca7D7C0mxq1OBGMOboga9qAThfn
Y5DGrcFn8zFslIfW2Vv3cyYe6PupkPJrMqjP5zfjfgXK8jDA+Wflam59NXBx8AiPxwIDAQAB
ozUwMzAjBgNVHREEHDAagRhib2JfbWNnb3dhbkBzeW1hbnRlYy5jb20wDAYDVR0TAQH/BAIw
ADANBgkqhkiG9w0BAQUFAAOBgQAafvlXVTPVMkFJvO0Y5KIZu2RINMz1giH+nV8yUtypjj8+
SpizR1w5dBwFBM1NJ9Of9PofklRli98n5Amu3uUdVUz0GXPvvwV5T2i5InmOQhdvn65sBTHc
ErFesk5IEI8HasCGlJLZZ3WpWAKCiQF7pJ5aBBpWOz9JhN1wjOEYbTCCAz8wggKooAMCAQIC
AQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENh
cGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAm
BgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0
ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1h
aWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNV
BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQD
EyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEF
AAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B
1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79A
gAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8E
CDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3
dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEa
MBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7M
DaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUa
C4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk1
3iSx0x1G/11fZU8xggNkMIIDYAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3
dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl
ZW1haWwgSXNzdWluZyBDQQIQKZCoUMR9Th+Lan5wqfmWpzAJBgUrDgMCGgUAoIIBwzAYBgkq
hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNzEyMTExNzQzMzdaMCMG
CSqGSIb3DQEJBDEWBBTOvdLZx9ybTYttwgN3qtxWoGiM4jBSBgkqhkiG9w0BCQ8xRTBDMAoG
CCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggq
hkiG9w0DAgIBKDCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMc
VGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFs
IEZyZWVtYWlsIElzc3VpbmcgQ0ECECmQqFDEfU4fi2p+cKn5lqcwgYcGCyqGSIb3DQEJEAIL
MXigdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg
THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECECmQ
qFDEfU4fi2p+cKn5lqcwDQYJKoZIhvcNAQEBBQAEggEAE9r5AN2WZDNDsACUUnPN2215CyhQ
qVdeMUjVUx8VSd26NPr+EqgBGcSMlEQylD1eLEJ9JZjcH9BE+ItmO/LUnJfN4a3I4wN9Ekml
Dc55B6ZHLFfxIxKY4Z9DnsBjx31hNOt4LWGKlqjl5DMp2XdaOnzQaWeL1X2rrAzWpdGirAIl
abDPSiBeS1KxQE+7QuvfY6p3rtN/avn4rPYExO98QAZgRKtaVbRtsM9IkLxGCGrrfO9j0owS
5bSxs4cK43jdLJSXMnKI9y4hjNPF8KXESoVCJIFWxkh8toKibhjk0ztK+0cOA1pL2TnAej83
pvC918+1LQ3gPe1JLfO4gAjYkgAAAAAAAA==
--------------ms070903020609090507040502--
Date: Mon, 10 Dec 2007 12:29:17 -0600
From: John Hasler <jhasler@debian.org>
To: debian-user@lists.debian.org
Subject: Re: How Linux becomes Windows
Message-ID: <87odcyz9mq.fsf@toncho.dhh.gt.org>
Content-Type: text/plain; charset=us-ascii
Sam Leon writes:
> HAL and udev have been standard in all desktops for awhile now.
I don't see how you can say that either is part of any desktop, though
kdebase depends on HAL (gnome-core depends on neither). Your system will
work fine without either (as will X). If he removes udev he will have to
do some stuff by hand, but he seems to want that.
> If you truly hate hal maybe you can just not install any desktop and just
> do all your computing through the console.
X is quite useable without any "desktop" and certainly does not require
HAL. Are you confounding "desktop" and "window mamager"?
--
John Hasler
Date: Tue, 11 Dec 2007 09:26:19 +0100
From: Katarzyna Kaczor <katarzyna.kaczor@lpmagazine.org>
To: debian-user@lists.debian.org
Subject: CoverCD Agreement - Debian
Message-Id: <200712110926.20098.katarzyna.kaczor@lpmagazine.org>
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Hello,
My name is Katarzyna Kaczor and I am an editorial assistant in Linux+=20
magazine.=20
The next 2/2008 issue of Linux+ will be devoted to Debian 4.0.=20
Many thanks to all from Linux community who prvided us with articles about=
=20
Debian, its installation, configuration, how-tos, tips&trics etc.=20
Do you mind if we re-distribute your Software with our publication?=20
We would like to feature Debian 4.0 distro on Linux+dvd. Could we also use=
=20
your product logo and graphics? =A0Could you give me the access to download=
it=20
via FTP.=20
Also, I would like to ask you for sending me a CoverCD Agreement.=20
I look forward on working with you. =A0
Thank you in advance for your kind help.
Kate
=2D-=20
Katarzyna Kaczor
Linux+ DVD magazine
www.lpmagazine.org/en
///////////////////////////////////////////////
Software Media LLC
1461 A First Avenue, # 360
New York, NY 10021-2209
USA
phone number: 1-917-338 - 3631/ +48 22 427 35 34
fax: =A0+48 22 887 10 11
www.lpmagazine.org/en
http://www.buyitpress.com/en/
Date: Tue, 11 Dec 2007 12:34:26 -0800
From: PETER EASTHOPE <peasthope@shaw.ca>
To: debian-user@lists.debian.org
Subject: location for user-specified iptable rules in Lenny
Message-id: <cc12fcef15ea9.475e83d2@shaw.ca>
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7bit
Content-disposition: inline
Mumia & others,
At 2007-09-12 11:57:52 -0500 Mumia W. Paduille wrote,
iptables -t nat -A PREROUTING -p tcp -s 12.140.16.4 --sport 22 -j REDIRECT --to-port 4122
& etc.
Right oh; thanks. I have the general picture. Seems
that what I aim for might be an instance of port forwarding.
In Lenny, where should a user specify iptable rules?
/etc/init.d/iptables is deprecated? Ipmasq is running
in the system already. Should I try to put my rules in
an ipmasq script? Should I install another firewall package?
Thanks for all replies, ... Peter E.
http://carnot.yi.org/
Date: Mon, 10 Dec 2007 11:16:47 -0800
From: David Brodbeck <brodbd@u.washington.edu>
To: Debian List <debian-user@lists.debian.org>
Subject: Re: OT: clicky keyboards
Message-Id: <350D472E-8BFD-473A-ABD7-F1EE72B793B2@u.washington.edu>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Content-Transfer-Encoding: 7bit
On Dec 10, 2007, at 11:13 AM, Andrew Sackville-West wrote:
> How about the Atari 800 (or was it the 400?) that had the bare
> membrane. ugh. now that was crap!
Fortunately I never had the displeasure of using one of those. I did
have to use an Atari 800XL for a while, at one job. That one at
least had real keys, although the touch wasn't any better than on a
Commodore keyboard.
Date: Fri, 07 Dec 2007 20:30:38 -0500
From: Max Hyre <max@hyre.net>
To: Debian User List <debian-user@lists.debian.org>
Subject: Re: OT: clicky keyboards
Message-ID: <4759F3BE.1010705@hyre.net>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Content-Transfer-Encoding: 7bit
David Brodbeck wrote:
> Yeah, but for $40 they take the thing apart and clean it before they
> sell it to you. That might just be worth every penny, given how
> disgusting those things get. I hope the guy who cleans them gets extra
> danger pay for the biohazard he's exposed to. ;)
I read some time (years) ago that you could send them
through the dishwasher. I never got up the nerve to try
that, but I sluiced one out in the sink (and I mean
thoroughly), and after a couple of days drying out it worked
fine. The keys no longer stuck, and I didn't have to look
at the cruft in the crevices. (Said cruft probably had
something to do with my habit of eating lunch at my desk. :-)
Best wishes,
Max Hyre
Date: Mon, 10 Dec 2007 13:07:34 -0800
From: Andrew Sackville-West <andrew@farwestbilliards.com>
To: debian-user@lists.debian.org
Subject: Re: OT: clicky keyboards
Message-ID: <20071210210734.GB7681@localhost.localdomain>
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature"; boundary="9MdG657QzbOEWl1C"
Content-Disposition: inline
--9MdG657QzbOEWl1C
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Mon, Dec 10, 2007 at 11:16:47AM -0800, David Brodbeck wrote:
>
> On Dec 10, 2007, at 11:13 AM, Andrew Sackville-West wrote:
>> How about the Atari 800 (or was it the 400?) that had the bare
>> membrane. ugh. now that was crap!
>
> Fortunately I never had the displeasure of using one of those. I did hav=
e=20
> to use an Atari 800XL for a while, at one job. That one at least had rea=
l=20
> keys, although the touch wasn't any better than on a Commodore keyboard.
I can remember typing in hundreds of lines of BASIC on that thing at
my buddy's house. Lucky for me, I had a C-64, so my own hacking was
not so impaired...
A
--9MdG657QzbOEWl1C
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFHXaqWaIeIEqwil4YRAm0NAKCqJ8q6D7FRWyvwU6IMgvPyeJQx6QCgqB5K
ZnvxuZNhQMHiQKWNzSGS8Fk=
=/Wny
-----END PGP SIGNATURE-----
--9MdG657QzbOEWl1C--
Date: Mon, 10 Dec 2007 23:30:46 +0100
From: Romain Francoise <rfrancoise@debian.org>
To: debian-user@lists.debian.org
Subject: Re: Gnus and emacs22
Message-ID: <87tzmqb2sp.fsf@elegiac.orebokech.com>
Content-Type: text/plain; charset=us-ascii
Peter Smerdon <psmerdon@magma.ca> writes:
> Hi, Gnus AFAIK, is included in emacs22 and emacs-snapshot. I think it
> might be the deveopment version called No Gnus, nevertheless, you can
> use this built in Gnus instead of the stand alone package.
In emacs22 the bundled Gnus is version 5.11, based on the stable
5.10 release.
In emacs-snapshot it's version 5.13, which is based on the yet
unreleased Gnus 5.12 (whose development codename is indeed No Gnus).
> PS: thank you Tatsuya Kinoshita and Romain Francoise for providing
> these packages! Now all I need is antialised fonts :-)
You're most welcome. You just need a little patience. :)
--
Romain Francoise <rfrancoise@debian.org>
http://people.debian.org/~rfrancoise/
Date: Mon, 10 Dec 2007 10:18:55 -0800
From: David Brodbeck <brodbd@u.washington.edu>
To: Debian <debian-user@lists.debian.org>
Subject: Re: OT: clicky keyboards
Message-Id: <1B41B554-E742-4133-8B3C-1F48B3BB9EB4@u.washington.edu>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Content-Transfer-Encoding: 7bit
On Dec 7, 2007, at 10:27 PM, Nate Duehr wrote:
> Humbug. If you learned hot to type *properly* on a real IBM
> Selectric (hint: you never pushed the key down past the "click",
> certainly never to the stops), using a clicky keyboard today won't
> cause you carpal tunnel any faster than a squish-box typed on
> improperly will. The click was meant to simulate the action of the
> typewriter ball smacking the paper for those of us who learned how
> to type on typewriters.
Right, that's the real trick. The "click" is supposed to cue your
brain to stop increasing pressure on that key and start pressing the
next one. All good keyboards have some kind of tactile feedback
before the key hits its stop; the IBM "clicky" keyboards have a
sharper and more defined version of this than most.
I noticed the importance of this pretty early when I realized how
much faster I could type on an IBM keyboard than on a Apple or
Commodore. The keyboards on the latter two machines had no tactile
feedback -- the keys just bottomed out. (Although neither was as bad
as the rubber "chiclet" keys on the PC Jr. ;) )
> To start with, real speed typists raise their hands off the board
> (the long "wrist rests" on most modern keyboards, especially
> laptops, simply didn't exist on typewriters -- people also didn't
> use them on their laps!). Incorrect technique is far more "risky"
> than using a "clicky" keyboard.
Uh huh. I'd go farther and say that those "wrist rests" they sell
for desktop keyboards are snake oil. Actually, they're worse than
snake oil. They actually encourage carpel tunnel syndrome, by
tempting people to place their wrists at a sharp angle. Your wrists
should be as straight as possible while typing.
I had wrist problems for a while, but it wasn't the fault of any
piece of hardware I was using -- it was my own lousy posture.
Date: Sat, 08 Dec 2007 12:42:06 -0600
From: Ron Johnson <ron.l.johnson@cox.net>
To: debian-user@lists.debian.org
Subject: Re: OT: clicky keyboards
Message-ID: <475AE57E.2000102@cox.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 12/08/07 12:17, Andrew Sackville-West wrote:
> On Sat, Dec 08, 2007 at 11:54:57AM -0600, Ron Johnson wrote:
>> Listening to people sing in Italian (or German) about incest and
>> matricide is not my cup of tea.
>
> sounds like a python bit
The language or the comedy troop?
Anyway, no one can convince me that opera is nothing more than
pre-television HBO.
- --
Ron Johnson, Jr.
Jefferson LA USA
"Your mistletoe is no match for my TOW missile." Santa-bot
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFHWuV+S9HxQb37XmcRAg3GAJ9kalccRpsq+Kq9cwZvjZ5uohgk3wCffus5
0+t3OfdVMDtd6ISA4hOogUU=
=bApH
-----END PGP SIGNATURE-----
Date: Tue, 11 Dec 2007 20:32:47 +0800
From: Uwe Dippel <udippel@uniten.edu.my>
To: debian-user@lists.debian.org
Subject: Network (LAN) 'lost'
Message-ID: <pan.2007.12.11.12.32.47.20102@uniten.edu.my>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
This morning, at boot, suddenly no LAN. The boot screen already had
some SIOCSIF errors. Solaris booted properly, with LAN.
In a nutshell, eth0 suddenly migrated to eth2, as one and only eth device=
.
Details:
This is what I get from dmesg:
...
ACPI: Processor [CPU1] (supports 16 throttling states)
8139cp: 10/100 PCI Ethernet driver v1.2 (Mar 22, 2004)
8139cp 0000:00:09.0: This (id 10ec:8139 rev 10) is not an 8139C+ compatib=
le chip
8139cp 0000:00:09.0: Try the "8139too" driver instead.
8139too Fast Ethernet driver 0.9.27
ACPI: PCI Interrupt 0000:00:09.0[A] -> GSI 18 (level, low) -> IRQ 169
eth0: RealTek RTL8139 at 0xd800, 00:02:44:90:97:27, IRQ 169
eth0: Identified 8139 chip type 'RTL-8100B/8139D'
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
...
And there is no other eth:
$ dmesg | grep eth
eth0: RealTek RTL8139 at 0xd800, 00:02:44:90:97:27, IRQ 169
eth0: Identified 8139 chip type 'RTL-8100B/8139D'
$
ifconfig says
# ifconfig
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:12 errors:0 dropped:0 overruns:0 frame:0
TX packets:12 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:600 (600.0 b) TX bytes:600 (600.0 b)
#
ifconfig does not 'up' eth0:
# ifconfig eth0 up
eth0: ERROR while getting interface flags: No such device
#
But it is in there:
# lspci -v
...
00:09.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL-8139/8139C/8139C+ (rev 10)
Subsystem: Realtek Semiconductor Co., Ltd. RT8139
Flags: bus master, medium devsel, latency 64, IRQ 169
I/O ports at d800 [size=3D256]
Memory at febff400 (32-bit, non-prefetchable) [size=3D256]
Capabilities: [50] Power Management version 2
Only "man ifconfig" gave me an idea:
# ifconfig -a
eth2 Link encap:Ethernet HWaddr 00:02:44:90:97:27
BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
Interrupt:169 Base address:0xd800
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:12 errors:0 dropped:0 overruns:0 frame:0
TX packets:12 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:600 (600.0 b) TX bytes:600 (600.0 b)
sit0 Link encap:IPv6-in-IPv4
NOARP MTU:1480 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
#
And it does work !:
# dhclient eth2
Internet Software Consortium DHCP Client 2.0pl5
Copyright 1995, 1996, 1997, 1998, 1999 The Internet Software Consortium.
All rights reserved.
Please contribute if you find this software useful.
For info, please visit http://www.isc.org/dhcp-contrib.html
sit0: unknown hardware address type 776
sit0: unknown hardware address type 776
Listening on LPF/eth2/00:02:44:90:97:27
Sending on LPF/eth2/00:02:44:90:97:27
Sending on Socket/fallback/fallback-net
DHCPREQUEST on eth2 to 255.255.255.255 port 67
DHCPACK from 192.168.116.200
bound to 192.168.116.101 -- renewal in 432000 seconds.
Now I ask myself WHY !?
How can a properly working system suddenly end up with a strange eth2
instead of eth0 ?
How does an eth0 recognised in dmesg at boot migrate to eth2; on its own =
?
Is this a bug ?
Uwe
Date: Tue, 11 Dec 2007 17:33:17 +0100
From: Gebhardt Thomas <gebhardt@hrz.uni-marburg.de>
To: debian-user@lists.debian.org
Subject: KDE doesn't connect to HAL
Message-Id: <200712111733.17935.gebhardt@hrz.uni-marburg.de>
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Hi,
I've several (KDE) etch systems that can't access removable devices
attached to the system.
In detail:
When I plug in an usb memory stick, nothing happens. No syslog entries
or whatsoever. But I can see the device with "lsusb".
When I klick on an icon in the konqueror "Storage Media" menu, then I get
the error message "Feature only available with HAL".
The menu item "Enable HAL backend" in "Control Center"->"Storage Media"
is greyed out, even when I start the Control Center as root.
Actually hald is running:
(but why does ps show the numerical uid "106" instead of "haldaemon" as the
process owner?)
# ps faux | grep hal
106 2707 0.0 0.2 6216 4696 ? Ss 16:32
0:01 /usr/sbin/hald
root 2708 0.0 0.0 2888 1032 ? S 16:32 0:00 \_
hald-runner
106 2714 0.0 0.0 1856 756 ? S 16:32 0:00 \_
hald-addon-acpi: listening on acpid socket /var/run/acpid.socket
106 2722 0.0 0.0 1852 768 ? S 16:32 0:00 \_
hald-addon-keyboard: listening on /dev/input/event0
106 2730 0.0 0.0 1856 768 ? S 16:32 0:00 \_
hald-addon-keyboard: listening on /dev/input/event4
106 2733 0.0 0.0 1856 764 ? S 16:33 0:00 \_
hald-addon-keyboard: listening on /dev/input/event3
root 2737 0.0 0.0 1808 620 ? S 16:33 0:00 \_
hald-addon-storage: polling /dev/scd0
root 5632 0.0 0.0 3740 760 pts/6 S+ 18:49 0:00 |
\_ grep hal
the same with dbus:
# ps faux | grep dbus
105 2699 0.0 0.1 7076 2352 ? Ss 16:32
0:00 /usr/bin/dbus-daemon --system
gebhardt 3087 0.0 0.0 4136 968 ? Ss 16:33 0:00
\_ /usr/bin/ssh-agent /usr/bin/dbus-launch --exit-with-session
x-session-manager
gebhardt 3090 0.0 0.0 2568 616 ? S 16:33
0:00 /usr/bin/dbus-launch --exit-with-session x-session-manager
gebhardt 3091 0.0 0.0 2468 444 ? Ss 16:33
0:00 /usr/bin/dbus-daemon --fork --print-pid 6 --print-address 8 --session
root 5648 0.0 0.0 3736 756 pts/6 S+ 18:51 0:00 |
\_ grep dbus
Any hint? Thanks a lot, Th. Gebhardt
End of debian-user-digest Digest V2007 Issue #2986
**************************************************
Received on Tue Dec 11 16:38:17 2007