Re: Faster source of random numbers [ "Douglas A. Tutty" <dtutty@porchlig ]
Re: cobol compiler/gui dev enviromen [ "Douglas A. Tutty" <dtutty@porchlig ]
Date: Thu, 25 Oct 2007 03:33:18 -0400
From: Kevin Mark <kevin.mark@verizon.net>
To: debian-user@lists.debian.org
Subject: Re: ps2pdf resizes page size to wrong format
Message-ID: <20071025073318.GD12561@horacrux>
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Thu, Oct 25, 2007 at 09:27:41AM +0200, Johannes Wiedersich wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>=20
> Hello all,
>=20
> I have two etch machines with practically very similar configuration.
> Due to some mechanism that is rather mysterious to me, if I convert the
> very same ps-file the page size is changed on one of the two machines,
> while the same command works correctly on the other machine.
>=20
> ps2pdf a.ps a.pdf
>=20
> produces a pdf with page size 210x297 mm on machine A and a pdf with the
> wrong size of 215.9x279.4 mm on machine B.
>=20
> The ps file is A4 (210 =D7 297 mm):
>=20
> /=3D=3D=3D a.ps =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
> %!PS-Adobe-2.0
> %%Creator: dvips(k) 5.95a Copyright 2005 Radical Eye Software
> %%Title: Blatt02.dvi
> %%Pages: 2
> %%PageOrder: Ascend
> %%BoundingBox: 0 0 595 842
> %%DocumentFonts: Helvetica Helvetica-Bold Helvetica-Oblique
> %%+ PazoMath-Italic Palatino-Italic PazoMath CMR10 Palatino-Roman CMSY10
> %%+ CMEX10
> %%DocumentPaperSizes: a4
> %%EndComments
>=20
> <snip>
> \=3D=3D=3D a.ps =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
>=20
> I can't find any hints on page settings in ps2pdf's documentation or how
> to force it or how it gets the idea of seemingly arbitrarily changing
> the page size.
>=20
> Thanks,
I'd try to investigate every file in /etc that deals with pdf or ps or
the reverse depends of ps2pdf. Maybe there is some value that is
different. Also are the reverse depends the same versions?
-K
--=20
| .''`. =3D=3D Debian GNU/Linux =3D=3D | my web site: |
| : :' : The Universal |mysite.verizon.net/kevin.mark/|
| `. `' Operating System | go to counter.li.org and |
| `-
http://www.debian.org/ | be counted! #238656 |
| my keyserver: subkeys.pgp.net | my NPO: cfsg.org |
|join the new debian-community.org to help Debian! |
|_______ Unless I ask to be CCd, assume I am subscribed _______|
Date: Thu, 25 Oct 2007 03:46:16 -0400
From: Rob Mahurin <rob@utk.edu>
To: debian-user@lists.debian.org
Subject: Re: Faster source of random numbers for blanking harddrives
Message-ID: <20071025074616.GA15317@localhost.localdomain>
Content-Type: multipart/mixed; boundary="C7zPtVaVf+AK4Oqc"
Content-Disposition: inline
--C7zPtVaVf+AK4Oqc
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename=mutt-koobeton-1000-26801-100
On Thu, Oct 25, 2007 at 02:19:59PM +0800, Bob wrote:
> if you type
> dd if=/dev/urandom of=/dev/null count=100000
> 100000+0 records in
> 100000+0 records out
> 51200000 bytes (51 MB) copied, 14.0076 seconds, 3.7 MB/s
>
> whereas
> dd if=/dev/zero of=/dev/null count=100000
> 100000+0 records in
> 100000+0 records out
> 51200000 bytes (51 MB) copied, 0.0932449 seconds, 549 MB/s
>
> Is there a faster source or random or pseudo-random numbers because at
> 4MB/s it'll take a loooong time to blank a 60GB drive let alone a 500GB job?
Most scientific libraries have fast, high-quality random number
generators. If you have libgsl0-dev installed, compile the attached
program with
$ make gsl_rng_info CFLAGS+="-lm -lgsl -lcblas -O6"
I get about 150 MB/s with the generator gfsr4:
$ time GSL_RNG_TYPE=gfsr4 ./gsl_random_spew spew | head -c 500m > /dev/null
GSL_RNG_TYPE=gfsr4
generator type: gfsr4
seed = 0
first value = 2901276280
real 0m3.467s
user 0m2.612s
sys 0m0.672s
My computer has a different bus speed from yours, etc., so experiment.
I don't know whether this generator fills all 32 bits of each
generated number, or its period; those are in the GSL info manual
(from which I cribbed most of this program). If you care about those
sorts of details, you might follow another poster's advice and
consider an existing solution.
Nota bene: don't call this program without redirecting stdout :)
Rob
--
Rob Mahurin
Dept. of Physics & Astronomy
University of Tennessee phone: 865 207 2594
Knoxville, TN 37996 email: rob@utk.edu
--C7zPtVaVf+AK4Oqc
Content-Type: text/x-csrc; charset=us-ascii
Content-Description: gsl_random_spew.c
Content-Disposition: attachment; filename="gsl_rng_info.c"
#include
#include
gsl_rng * r; /* global generator */
#define CHUNKSIZE (1024*1024)
/*
* Calling this program with any arguments will spew infinite amounts
* of binary data to your terminal. Caveat emptor.
*/
int main (int argc, char* argv[])
{
const gsl_rng_type * T;
gsl_rng_env_setup();
T = gsl_rng_default;
r = gsl_rng_alloc (T);
fprintf (stderr,"generator type: %s\n", gsl_rng_name (r));
fprintf (stderr,"seed = %lu\n", gsl_rng_default_seed);
fprintf (stderr,"first value = %lu\n", gsl_rng_get (r));
if (argc==1) return 0;
else {
/* spew binary data to stdout */
unsigned long random_chunk[CHUNKSIZE];
int i =0;
while (1) {
for (i = 0; i
Date: Thu, 25 Oct 2007 09:03:41 +0100
From: Magnus Therning <magnus@therning.org>
To: debian-user@lists.debian.org
Subject: Re: Strange X problem--right mouse kills X
Message-ID: <20071025080341.GC24069@die.therning.org>
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature"; boundary="gr/z0/N6AeWAPJVB"
Content-Disposition: inline
--gr/z0/N6AeWAPJVB
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Wed, Oct 24, 2007 at 10:59:12 -0700, javi78 wrote:
>
>Today after upgrade my debian Sid, many keys of my keyboard didn't work
>properly. For example, Alt-Gr key had the enter function, when I pushed
>"up" direction key the Ksnapshot was launched, etc. Then I saw in this
>forum that the package xserver-xorg-input-evdev could have a problem
>with other modules related to xorg. To remove xserver-xorg-input-evdev
>with apt-get remove xserver-xorg-input-evdev solved my problem.
>Thank you very much for your help.
It turns out the easier solution is to get rid of
/usr/share/hal/fdi/policy/10osvendor/10-xx-input.fdi. It caused evdev
to be used in X.
It seems my latest update (in Sid) has removed the file from that
location. Things are now back to normal again :-)
/M
--=20
Magnus Therning (OpenPGP: 0xAB4DFBA4)
magnus=EF=BC=A0therning=EF=BC=8Eorg Jabber: magnus=EF=BC=8Ether=
ning=EF=BC=A0gmail=EF=BC=8Ecom
http://therning.org/magnus
--gr/z0/N6AeWAPJVB
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)
iD8DBQFHIE3diMWTaatN+6QRAsrtAKCs/M/c7wGfcNEQ4VdIoEkoQ9GSGACg3rcK
181nqtuzBtszToZZ5Qifq14=
=zb7R
-----END PGP SIGNATURE-----
--gr/z0/N6AeWAPJVB--
Date: Thu, 25 Oct 2007 09:56:13 +0200
From: Johannes Wiedersich <johannes@physik.blm.tu-muenchen.de>
To: debian-user@lists.debian.org
Subject: [solved] Re: ps2pdf resizes page size to wrong format
Message-Id: <47204C1D.8010800@physik.blm.tu-muenchen.de>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Kevin Mark wrote:
> I'd try to investigate every file in /etc that deals with pdf or ps or
> the reverse depends of ps2pdf. Maybe there is some value that is
> different. Also are the reverse depends the same versions?
Thanks!
It turned out to be /etc/papersize
/===========================
mybox:/etc# cat /etc/papersize
a4
\===========================
did it.
Funny though, that dvips obeys the document specific paper size, while
ps2pdf ignores the document's settings. At the same time dvips has an
option to change the paper size 'on the fly', while ps2pdf does not.
(Latex users should be able select a paper size within the document
"documentclass[a4paper]..." etc. and not via /etc/papersize, IMHO. On
the other hand applications like iceweasel -- where a system wide paper
size makes much more sense: all printers on a system typically offer the
same paper size -- ignore /etc/papersize and always use "letter". )
Johannes
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFHIEwdC1NzPRl9qEURAhQ4AJ9U6haoHI75Y/uc/ULP/Nm4hc7tPgCfeTJq
dmx17392rgzQ1UXh4zizuao=
=MrW1
-----END PGP SIGNATURE-----
Date: Thu, 25 Oct 2007 10:05:40 +0200
From: Florian Kulzer <florian.kulzer+debian@icfo.es>
To: debian-user@lists.debian.org
Subject: Xorg keyboard and mouse problems (was: Strange X problem--right
mouse kills X)
Message-ID: <20071025080540.GA31551@pc0197>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
On Wed, Oct 24, 2007 at 10:59:12 -0700, javi78 wrote:
>
> Today after upgrade my debian Sid, many keys of my keyboard didn't work
> properly. For example, Alt-Gr key had the enter function, when I pushed "up"
> direction key the Ksnapshot was launched, etc.
> Then I saw in this forum that the package xserver-xorg-input-evdev could
> have a problem with other modules related to xorg. To remove
> xserver-xorg-input-evdev with apt-get remove xserver-xorg-input-evdev solved
> my problem.
It seems that this issue is fixed now, at least as far as the non-US
keyboard layouts are concerned. Today I upgraded to hal 0.5.10-2 and
reinstalled xserver-xorg-input-evdev (1:1.2.0~git20070819-3). My ES
keyboard still works even when I force Xorg to load the evdev module.
--
Regards, | http://users.icfo.es/Florian.Kulzer
Florian |
Date: Thu, 25 Oct 2007 16:46:08 +0800
From: Bob <spam@homeurl.co.uk>
To: debian-user@lists.debian.org
Subject: Re: Faster source of random numbers for blanking harddrives
Message-ID: <472057D0.90901@homeurl.co.uk>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Ron Johnson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 10/25/07 01:19, Bob wrote:
>
>> if you type
>> dd if=/dev/urandom of=/dev/null count=100000
>> 100000+0 records in
>> 100000+0 records out
>> 51200000 bytes (51 MB) copied, 14.0076 seconds, 3.7 MB/s
>>
>> whereas
>> dd if=/dev/zero of=/dev/null count=100000
>> 100000+0 records in
>> 100000+0 records out
>> 51200000 bytes (51 MB) copied, 0.0932449 seconds, 549 MB/s
>>
>> Is there a faster source or random or pseudo-random numbers because at
>> 4MB/s it'll take a loooong time to blank a 60GB drive let alone a 500GB
>> job?
>>
>> Maybe we could use 10 (or 100) files on RAM disk each 1MB in size filled
>> by /dev/urandom, then use /dev/random and some algorithm to determine
>> what portion of what file to use, using random to string together chunks
>> of pseudo-random files, you could also randomly replace/refill files,
>> it's not ideal but it should be good enough and if we could get it fast
>> enough so that it's the drive write speed that the bottle neck that
>> would be perfect.
>>
>> What other options are there?
>>
>
> Why roll your own when there are *MANY* disk wipers out there.
> Everything from srm & sfill in the secure-delete package, to wipe,
> to dban.sourceforge.net.
Thank you, reading up on them now. I was just wondering if there was
another standard device I could use on all systems.
Date: Thu, 25 Oct 2007 10:16:30 +0100
From: "Rosin, Angela" <lister@liverpool.ac.uk>
To: <debian-user@lists.debian.org>
Subject: Slow scp/graphics connection.
Message-ID: <DBFE669A5855604AB7274F8FE386F746018B7C47@EVSSTAFF2.livad.liv.ac.uk>
Content-class: urn:content-classes:message
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Apologies if you are seeing this twice: for some reason my account =
started bouncing the group yesterday and I had to resub.
I have a suite of 11 computers running debian etch (2.6.18-3-686 server, =
2.6.18-4-686 on the nodes). We use Condor and nfs to manage user =
accounts from a central server. Recently I've noticed an intermittent =
problem with graphical login: it takes a long time to log in and =
applications are slow. This is odd as it's only the home directory that =
is exported - everything else is managed on the node. I've also had a =
problem today with scp. A 12MB file takes 2 minutes and spents a lot of =
time stalled. The network team have checked that it isn't a problem =
their end so I'm assuming it's a problem with this machine, either with =
the network card or transfer protocal compatibility issues. I've had a =
mooch round the web but networking is so far out of my comfort zone I'm =
practically perching on broken glass and my normal response would be to =
restart the server. As I've users running long jobs I'd appreciate some =
pointers to fixing it without resorting to a restart.
What I have done so far: I've checked that the nfsd daemons are =
running. I've restarted portmap. I've run top to see if there is a =
rogue process running, ditto ps. The machines use KDE as default and we =
are on 3.5. Does anyone have an idea of where I should be looking to =
improve performance/iron out a problem. I've attached ping output as =
well as ifconfig for the server.
Thanks in advance for any help you can give.
Ang
Outward ping (server to node) is
7 packets transmitted, 7 received, 0% packet loss, time 6009ms rtt =
min/avg/max/mdev =3D 8.020/35.689/41.240/11.334 ms
Inward ping (node to server) is
8 packets transmitted, 8 received, 0% packet loss, time 7005ms rtt =
min/avg/max/mdev =3D 27.802/32.252/37.664/3.603 ms
Output of ifconfig -a
eth0 Link encap:Ethernet HWaddr 00:13:72:75:15:E2
inet addr:138.253.199.46 Bcast:138.253.199.255 =
Mask:255.255.252.0
inet6 addr: fe80::213:72ff:fe75:15e2/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:588806152 errors:0 dropped:0 overruns:0 frame:0
TX packets:3795714138 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:3204959342 (2.9 GiB) TX bytes:2429011615 (2.2 GiB)
Base address:0xdcc0 Memory:dfee0000-dff00000
eth1 Link encap:UNSPEC HWaddr =
80-75-00-13-15-E2-72-00-00-00-00-00-00-00-00-00
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)
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:767193 errors:0 dropped:0 overruns:0 frame:0
TX packets:767193 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1554133767 (1.4 GiB) TX bytes:1554133767 (1.4 GiB)
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)
Date: Thu, 25 Oct 2007 11:45:31 +0200
From: Josip Rodin <joy@entuzijast.net>
To: debian-user@lists.debian.org, debian-mirrors@lists.debian.org
Subject: ftp.us.d.o/http.us.d.o updated
Message-ID: <20071025094531.GA500@keid.carnet.hr>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Hi,
I just wanted to let people know that we changed the ftp.us.debian.org
and http.us.debian.org aliases to match, and include five mirrors
(up from two and four, resp.).
If anyone notices problems with apt-get or something, let us know at
at the debian-mirrors list or at mirrors@d.o.
--
Josip Rodin
mirrors@debian.org
Date: Thu, 25 Oct 2007 11:37:33 +0200
From: =?ISO-8859-1?Q?J=F6rg-Volker_Peetz?= <peetz@scai.fraunhofer.de>
To: debian-user@lists.debian.org
Subject: Re: Listing packages
Message-ID: <ffpo4t$186$1@ger.gmane.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
David Fox wrote:
> On 10/24/07, David Clymer <david@zettazebra.com> wrote:
>> On Tue, 2007-10-23 at 11:28 +0200, J=F6rg-Volker Peetz wrote:
>=20
>>> aptitude can do that:
>>>
>>> aptitude -F '%p %t' search '~i'
>=20
> That produces (imho) misleading output. It is telling me that I have
> many more packages that come from unstable then I believe I should
> have on a testing system. I have set pinning to prefer testing over
> stable, but I've also installed a few packages from unstable - mostly
> those that relate to X and nvidia stuff that isn't available in
> testing (specifically, nvidia-kernel-source && nvidia-glx).
>=20
> Yet, for instance, it says 'tar' comes from unstable.
>=20
> apt-cache policy says:
>=20
> tar:
> Installed: 1.18-2
> Candidate: 1.18-2
> Version table:
> 1.19-1 0
> 600 http://ftp.debian.org sid/main Packages
> *** 1.18-2 0
> 990 http://ftp.debian.org testing/main Packages
> 100 /var/lib/dpkg/status
>=20
> So, what is that aptitude command telling me?
>=20
>=20
In the manual the description of the '%t' says
"The archive in which the package is found."
And aptitude seems to list the archive with the lowest priority.
So my advice about the aptitude command is indeed misleading since
aptitude does not tell from which archive the installed version of the
package was taken.
Thanks for correcting me.
Therefore the script of David Clymer is the only working solution.
--=20
Regards,
J=F6rg-Volker.
Date: Thu, 25 Oct 2007 21:17:38 +1000
From: Greg Vickers <daehenoc@optusnet.com.au>
To: debian-user@lists.debian.org
Subject: grub boot problem with md
Message-ID: <47207B52.8010206@optusnet.com.au>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Hi all,
I've got a Dell PowerEdge 830 that I've set up md raid1 on. grub was
installed as part of the installation process and I recently installed
grub on sdb with the following commands:
grub> device (hd0) /dev/sdb
grub> root (hd0,1)
grub> setup (hd0)
The root partition is 1 on both these drives (see fdisk output below).
Here is the default boot from menu.lst:
title Debian GNU/Linux, kernel 2.6.18-4-686
root (hd0,1)
kernel /vmlinuz-2.6.18-4-686 root=/dev/md3 ro
initrd /initrd.img-2.6.18-4-686
Here are the relevant bits from mdstat:
# cat /proc/mdstat
Personalities : [raid1]
md3 : active raid1 sda3[0] sdc3[2](S) sdb3[1]
979840 blocks [2/2] [UU]
md2 : active raid1 sda2[0] sdc2[2](S) sdb2[1]
289088 blocks [2/2] [UU]
Here are the relevant mounted paritions:
# mount
/dev/md3 on / type ext3 (rw,errors=remount-ro)
/dev/md2 on /boot type ext3 (rw)
And output from fdisk:
# fdisk -l /dev/sda
Device Boot Start End Blocks Id System
/dev/sda1 1 7 56196 de Dell Utility
/dev/sda2 * 8 43 289170 fd Linux raid
/dev/sda3 44 165 979965 fd Linux raid
# fdisk -l /dev/sdb
Device Boot Start End Blocks Id System
/dev/sdb1 1 7 56196 de Dell Utility
/dev/sdb2 * 8 43 289170 fd Linux raid
/dev/sdb3 44 165 979965 fd Linux raid
I power down the server and remove the first HDD, then power up the
server and set the BIOS to boot off the second HDD. As the server
starts, I *think* I see the message "GRUB ..." for about five
microseconds before the screen goes black and the only thing that is on
the screen is the following message:
"Console redirection code"
And the server does not boot off the second HDD. I've looked through
all of menu.lst and console redirection is not configured to be active.
I have also copied the MBR from sda to sdb and the same problem
happens. Have I done something wrong with grub or is this something
weird and Dell specific?
Thanks,
Greg
Date: Thu, 25 Oct 2007 14:33:48 +0200
From: Thierry Chatelet <tchatelet@free.fr>
To: debian-user@lists.debian.org
Subject: Web cam Philips 0471:032d not seen
Message-Id: <200710251433.48390.tchatelet@free.fr>
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Hi,
I just got this webcam, according to gspca maintener' site
(http://mxhaard.free.fr/spca5xx.html), it should work 'out of the box',
unfortunately, I cannot get mine to work.
It is suppose to use module gspca.
Here are the output of what I tried:
lsusb:
Bus 002 Device 003: ID 0471:032d Philips
When it the webcam is plugged in, it should load the module, but it doesnot.
So I did modprobe gspca, and here is the output of dmesg:
Linux video capture interface: v2.00
usbcore: registered new driver gspca
/build/buildd/linux-modules-extra-2.6-2.6.18/debian/build/build_amd64_none_amd64_gspca/gspca_core.c:
gspca driver 2.6.18 registered
Now, on the maintener site the product ID 032d indicate a Philips SPC210NC,
and the sticker on mine indicate SPC215NC.
What else can I try to have it recognize?
Oh: I am running AMD64-Etch, and I tried the cam at a friend place running $W,
it is working.
Thanks
Thierry
Date: Thu, 25 Oct 2007 05:51:56 -0700
From: Rogelio <scubacuda@gmail.com>
To: debian-user@lists.debian.org
Subject: DNS CNAME question
Message-ID: <2b7af7c40710250551u1e6217e2g3a80406f5484d8fe@mail.gmail.com>
Content-Type: multipart/alternative;
boundary="----=_Part_1049_15574816.1193316716981"
------=_Part_1049_15574816.1193316716981
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Not sure if this is the best place to ask this question (and if so, please
point me to a better listserv), but is there anything "wrong" RFC or best
practice wise with pointing a CNAME record to a DNS server?
(I'm using EveryDNS.net, and I'd like to make my CNAME records ns1->
4.myDomain.com correspond to ns1->ns4.EveryDNS.net.)
------=_Part_1049_15574816.1193316716981
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
<div>Not sure if this is the best place to ask this question (and if so, please point me to a better listserv), but is there anything "wrong" RFC or best practice wise with pointing a CNAME record to a DNS server?
</div>
<div> </div>
<div>(I'm using EveryDNS.net, and I'd like to make my CNAME records ns1->4.myDomain.com correspond to ns1->ns4.EveryDNS.net.)</div>
------=_Part_1049_15574816.1193316716981--
Date: Thu, 25 Oct 2007 09:22:49 -0400
From: "Douglas A. Tutty" <dtutty@porchlight.ca>
To: debian-user@lists.debian.org
Subject: Re: Silly question: Where's eth0?
Message-ID: <20071025132249.GD6408@titan.hooton>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
On Wed, Oct 24, 2007 at 09:45:54PM -0700, francisco wrote:
> El mi??, 24-10-2007 a las 22:27 -0400, Douglas A. Tutty escribi??:
> > On Wed, Oct 24, 2007 at 07:00:39PM -0700, francisco wrote:
> > > El mi??, 24-10-2007 a las 10:11 -0400, Douglas A. Tutty escribi??:
> > > > On Wed, Oct 24, 2007 at 10:02:31AM +0200, Matthias Feichtinger wrote:
> > > > > I had the same problem.
> > > > > The mistake was made while installing.
> > > > > It is not possible to change things, e.g. having to configure more
> > > > > than one ethernetcard.
> > > > Are you seriously telling people that you can't add a NIC to Debian
> > > > without re-installing? Get a life.
> > > Could you, forget the theoretical explanation and show it by a simple
> > > example? i have the same problem, and it can not be solve by ifconfig,
> > > iwconfig, route and others. Broadcom card 4311, Compaq Presario v3019US.
> > >
>
> > It seems that the linux driver for your card requires that you steal the
> > firmware from another driver and stick it into the linux driver. Good
> > luck with that.
> >
> > Now, if you actually had a piece of hardware that _was_ fully supported
> > by the linux kernel without this mess, then you would get a functioning
> > eth0 which would then work just fine with the standard Debian networking
> > tools.
> >
> > In short, your problem isn't with the networking tools, its with a
> > non-functional driver.
>
> Ah, ok i understand that you can not do it!. You can only in theory!
>
You challenged me on setting up two NICs in Linux, not about getting a
half-assed driver to work. Two different problems.
Doug.
Date: Thu, 25 Oct 2007 09:27:50 -0400
From: "Douglas A. Tutty" <dtutty@porchlight.ca>
To: debian-user@lists.debian.org
Subject: Re: Faster source of random numbers for blanking harddrives
Message-ID: <20071025132750.GE6408@titan.hooton>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
On Thu, Oct 25, 2007 at 04:46:08PM +0800, Bob wrote:
> Ron Johnson wrote:
> >On 10/25/07 01:19, Bob wrote:
> >>Is there a faster source or random or pseudo-random numbers because at
> >>4MB/s it'll take a loooong time to blank a 60GB drive let alone a 500GB
> >>job?
> >>
> >>What other options are there?
> >>
> >
> >Why roll your own when there are *MANY* disk wipers out there.
> >Everything from srm & sfill in the secure-delete package, to wipe,
> >to dban.sourceforge.net.
>
> Thank you, reading up on them now. I was just wondering if there was
> another standard device I could use on all systems.
OpenSSL has rand
If you have another source of data the size of your drive, run openssl
enc on the raw partition. It all depends on the non-repeat-length you
need.
Doug.
Date: Thu, 25 Oct 2007 09:01:20 -0400
From: "Douglas A. Tutty" <dtutty@porchlight.ca>
To: debian-user@lists.debian.org
Subject: Re: cobol compiler/gui dev enviroment
Message-ID: <20071025130120.GA6408@titan.hooton>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
On Wed, Oct 24, 2007 at 09:56:03PM -0500, Ron Johnson wrote:
> On 10/24/07 18:03, Chris Parker wrote:
> >
> > Thanks for the responses. We do now use microfocus, but that is running
> > on SCO. I was looking for a Linux version less expensive. Licensing
> > for Microfocus on Linux is $500,000 for everything. This is too keep
> > from having to go to Windows environment.
>
> $500,000??? There's a lot of "everything" that you're not telling
> us about. Dozens of developer seats, thousands of CALs, "gold"
> service contract, etc?
>
> Is it that much more expensive than the SCO or Windows license?
Which certainly changes the potential answers to the "why COBOL"
question I asked that was never answered by the OP.
Doug.
End of debian-user-digest Digest V2007 Issue #2676
**************************************************
Received on Thu Oct 25 09:57:58 2007