Hi branden and others in xfree 4.2 project:
(sorry with my poor english but i'm spanish)
I wonder if the new neomagic driver from cvs could be included in this 4.2
debs. The 4.2 neomagic driver has no support for XV extensions and thus we
cannot play videos. The videos are VERY slow more or les
On Mon, 2002-08-26 at 14:36, Scott Henson wrote:
> On Mon, 2002-08-26 at 03:46, Michel Dänzer wrote:
> > On Mon, 2002-08-26 at 04:27, Scott Henson wrote:
>
> > > and I cannot start it with startx as a normal user, though root can.
> > > xinit does bring up XF86 though. When using startx the x serv
On Mon, Aug 26, 2002 at 09:10:54PM +0200, Marcus Brinkmann wrote:
> On Mon, Aug 26, 2002 at 12:50:22PM -0500, Branden Robinson wrote:
> > > I can't believe he actually intends to keep it like this..
> >
> > I'm going to #define DEV_RANDOM /dev/random for Linux systems.
>
> That's bad, because tha
On Mon, Aug 26, 2002 at 03:30:43PM -0300, John Lenton wrote:
> Hi all.
>
> I downloaded -pre1v3, and tried it against my ATI Radeon 64MB DDR
> VIVO, with mixed results:
>
> - DRI worked (that's up from the last time I looked :)
Glad to hear it.
> - X took a long time to start ("long" in compari
OK folks, the banter is getting excessive. I'll have to bail if the dialog
can't be kept more point to point instead of broadcast.
[EMAIL PROTECTED]
-Original Message-
From: Marcus Brinkmann
To: [EMAIL PROTECTED]; debian-x@lists.debian.org
Sent: 8/26/02 3:59 PM
Subject: Re: a small C pr
On Mon, Aug 26, 2002 at 02:44:26PM -0500, Branden Robinson wrote:
> On Mon, Aug 26, 2002 at 03:28:18PM -0400, Jeff Sheinberg wrote:
> > Why does anyone need to read megabytes of urandom?
>
> Nobody does. Or, at least, xdm doesn't. Markus is opining without the
> benefit of having checked the fac
On Mon, Aug 26, 2002 at 02:43:09PM -0500, Branden Robinson wrote:
> xdm doesn't read the same amount of data when it's reading from a
> (presumably) entropic device node.
I didn't assume that.
> It reads eight size_t's. Surely that is not excessive.
It's eight size_t's good entropy wasted for n
On Mon, Aug 26, 2002 at 03:28:18PM -0400, Jeff Sheinberg wrote:
> Why does anyone need to read megabytes of urandom?
Nobody does. Or, at least, xdm doesn't. Markus is opining without the
benefit of having checked the facts.
--
G. Branden Robinson| What influenced me to athe
On Mon, Aug 26, 2002 at 09:10:54PM +0200, Marcus Brinkmann wrote:
> On Mon, Aug 26, 2002 at 12:50:22PM -0500, Branden Robinson wrote:
> > > I can't believe he actually intends to keep it like this..
> >
> > I'm going to #define DEV_RANDOM /dev/random for Linux systems.
>
> That's bad, because tha
Marcus Brinkmann writes:
> On Mon, Aug 26, 2002 at 12:50:22PM -0500, Branden Robinson wrote:
> > > I can't believe he actually intends to keep it like this..
> >
> > I'm going to #define DEV_RANDOM /dev/random for Linux systems.
>
> That's bad, because that will drain the entropy a lot, and
On Mon, Aug 26, 2002 at 08:16:06PM +0100, Matthew Wilcox wrote:
> On Mon, Aug 26, 2002 at 09:10:54PM +0200, Marcus Brinkmann wrote:
> > Also, reading /dev/mem doesn't sound very secure at all (even if it works)
> > because the patterns in the memory of a computer are probably predictable
> > and a
On Mon, Aug 26, 2002 at 09:10:54PM +0200, Marcus Brinkmann wrote:
> Also, reading /dev/mem doesn't sound very secure at all (even if it works)
> because the patterns in the memory of a computer are probably predictable
> and a lot of information can be observed from the outside (which processes
> a
On Mon, Aug 26, 2002 at 12:50:22PM -0500, Branden Robinson wrote:
> > I can't believe he actually intends to keep it like this..
>
> I'm going to #define DEV_RANDOM /dev/random for Linux systems.
That's bad, because that will drain the entropy a lot, and it might
block for a long time, and that f
On Mon, Aug 26, 2002 at 07:46:27PM +0100, mallum wrote:
> on Mon, Aug 26, 2002 at 03:30:43PM -0300, John Lenton wrote:
> >
> > Is there any reason RandR isn't being included? AFAICT it isn't
> > in any of the servers (if that's so, why include xrandr -- the
> > program -- at all?).
> >
>
> I bel
on Mon, Aug 26, 2002 at 03:30:43PM -0300, John Lenton wrote:
>
> Is there any reason RandR isn't being included? AFAICT it isn't
> in any of the servers (if that's so, why include xrandr -- the
> program -- at all?).
>
I believe RandR currently only works on TinyX ( aka kdrive ) framebuffer base
Hi all.
I downloaded -pre1v3, and tried it against my ATI Radeon 64MB DDR
VIVO, with mixed results:
- DRI worked (that's up from the last time I looked :)
- X took a long time to start ("long" in comparison, nothing
serious, i.e. a several seconds longer than usual), and my
monitor seemed to loos
> I'm wondering if XFree86 considers it worth the trouble.
I have no doubt that a tested, cross-platform patch will be accepted.
Non-portable patches are sometimes considered more trouble than they
are worth.
(You should at least consider Linux, the three Free BSDs, Solaris,
Lynx and OS X, on all
CAPT. PAUL DIMANGO.
TEL. 27 73 234 9108.
FAX 27 72 486 3248.
Dear Sir,
URGENT INVESTMENT OFFER
I know you will be surprise to receive this email from me,
but please this letter is a request from
someone in dare need of assistance. I Capt. PAUL DIMANGO from Angola, a
personal aide
to the late
On Mon, Aug 26, 2002 at 10:23:06AM -0400, Joey Hess wrote:
> matthew green wrote:
> > bad ideas often hang around for a long time. the only surprising
> > thing to me is how long this one has taken to surface...
>
> Perhaps Branden is gathering information about what a bad idea this
> really is,
On Mon, Aug 26, 2002 at 11:13:08AM +0200, Wichert Akkerman wrote:
> Previously Kimmo K. I. Surakka wrote:
> > I think the "safe" way of getting random data without a decent random
> > source would be to write one. This, however, would be more that just
> > a small patch.
>
> There is existing code
On Mon, Aug 26, 2002 at 10:34:45AM +0200, Thomas Horsten wrote:
> > On Mon, Aug 26, 2002 at 05:04:26PM +1000, matthew green wrote:
> > > actually, i hadn't, but there wasn't very much there besides the
> > > fact that people found it was xdm reading /dev/mem and a small
> > > patch for debian to en
[EMAIL PROTECTED]:~/tmp$ sudo ./test
Reading data from /dev/mem...
read #2 of 8192 bytes
read #3 of 8192 bytes
read #4 of 8192 bytes
read #5 of 8192 bytes
read #6 of 8192 bytes
read #7 of 8192 bytes
read #8 of 8192 bytes
read #9 of 8192 bytes
read #10 of 8192 bytes
read #11 of 8192 bytes
On Mon, 2002-08-26 at 08:20, Branden Robinson wrote:
>
> I need people with root on machines of your given architecture to
> compile and run the attached C program. It consists of code borrowed
> from xdm's genauth.c program.
>
Branden,
In the hope that this report is useful to you, I compile
Updated sources.list, apt-get update and then dist-upgrade. Worked
fine, no problems during the upgrade. Runs great, not experienced any
problems, thus far. One point of interest though :
>From running startx, gnome (1.4) launches much quicker than on XF86
4.1.x (used to be about 10 secs from s
On Mon, Aug 26, 2002 at 09:06:00AM -0400, Carlos O'Donell wrote:
> Done. I've submitted the output for HPPA boxes running 32 and 64-bit
> kernels. Looks like they pass without any problem. I'll pass on the
yes, but it may well crash them. some parts of /dev/mem map random IO
addresses which may
Happy to help...works fine on both my systems.
...testing on Celery 450Mhz, Unstable
read #1023 of 8192 bytes
read #1024 of 8192 bytes
done with read of /dev/mem (returned 1).
sumFile() succeeded.
...and just for the record with the fragile arg :
read #1023 of 8192 bytes
read #1024 of 8192 b
matthew green wrote:
> bad ideas often hang around for a long time. the only surprising
> thing to me is how long this one has taken to surface...
Perhaps Branden is gathering information about what a bad idea this
really is, to show upstream the error of their ways. I can't believe he
actually i
on my pc164lx running woody 2.4.18 kernel with 512M mem.
read #1022 of 16384 bytes
read #1023 of 16384 bytes
read #1024 of 16384 bytes
done with read of /dev/mem (returned 1).
sumFile() succeeded.
ganesha:~# cat /proc/cpuinfo
cpu : Alpha
cpu model : EV56
cpu va
Branden,
> The long story, for those interested:
> http://lists.debian.org/debian-x/2002/debian-x-200208/msg00091.html
> (and read the whole thread)
> The short story:
> I need people with root on machines of your given architecture to
> compile and run the attached C program. It consists of cod
On Monday 26 Aug 2002 7:20 am, Branden Robinson wrote:
> I need people with root on machines of your given architecture to
> compile and run the attached C program. It consists of code borrowed
> from xdm's genauth.c program.
Runs OK on hppa (712/80, hppa1.1, Woody).
On Mon, 2002-08-26 at 03:46, Michel Dänzer wrote:
> On Mon, 2002-08-26 at 04:27, Scott Henson wrote:
> > > GATOS doesn't do 2D acceleration AFAIK, don't you mean 3D anyway?
> > >
> > > Either way, try
> > >
> > > deb http://penguinppc.org/~daenzer/debian/dri-trunk/./
> >
> > I upg
On Monday 26 August 2002 02:20 am, Branden Robinson wrote:
> I and the other folks at the X Strike Force need to know the following
> things:
>
> 1) whether or not this program works when you run it without arguments
> 2) if scenario 1) causes problems, what the last line of output was
> 3) if scen
I tested it on an R4600SC (SGI Indy) running Debian unstable: indy
2.4.17-r4k-ip22
I ran it twice with and without the fragile argument.
No arguments gave:
read #66 of 8192 bytes the first time,
read #73 of 8192 bytes the second time.
With fagile argument:
Reading data from (fragile) /dev/mem.
matthew green <[EMAIL PROTECTED]> writes:
> my point is that on modern systems we simply should not read
> from /dev/mem for these purposes _ever_.
It would make some sense to read all the physical memory in the
machine. Unfortunately, I'm not aware of any reasonably way to do
that. Reading /dev/
Previously Kimmo K. I. Surakka wrote:
> I think the "safe" way of getting random data without a decent random
> source would be to write one. This, however, would be more that just
> a small patch.
There is existing code to generate randomness from userland, look at
what current OpenSSH does for e
> On Mon, Aug 26, 2002 at 05:04:26PM +1000, matthew green wrote:
> > actually, i hadn't, but there wasn't very much there besides the
> > fact that people found it was xdm reading /dev/mem and a small
> > patch for debian to enable /dev/random (i'd suggest /dev/urandom).
>
> If any of these it shou
Filip Van Raemdonck <[EMAIL PROTECTED]> wrote:
> On Mon, Aug 26, 2002 at 05:04:26PM +1000, matthew green wrote:
> > actually, i hadn't, but there wasn't very much there besides the
> > fact that people found it was xdm reading /dev/mem and a small
> > patch for debian to enable /dev/random (i'd sug
On Mon, 26 Aug 2002 17:04:26 +1000
"matthew green" <[EMAIL PROTECTED]> wrote:
> actually, i hadn't, but there wasn't very much there besides the
> fact that people found it was xdm reading /dev/mem and a small
> patch for debian to enable /dev/random (i'd suggest /dev/urandom).
>
> my point is th
Hi,
On Mon, Aug 26, 2002 at 05:04:26PM +1000, matthew green wrote:
>
> > > why don't you use /dev/urandom if it exists, as it does on pretty
> > > much all modern UNIX platforms?
> >
> > I see you haven't read the thread.
>
>
> actually, i hadn't, but there wasn't very much there besides the
Hello,
We understand you are interested in "genuine" home-based businesses that offer
security and peace of mind, as well as an excellent income.
If this is the case, we sincerely believe we may have just what you are looking
for ... superb incomes from low risk, financially sound companies ba
On Mon, 2002-08-26 at 04:27, Scott Henson wrote:
> On Sat, 2002-08-24 at 21:08, Michel Dänzer wrote:
> > On Sun, 2002-08-25 at 02:55, Csan wrote:
> > >
> > > > > is there any chance for gatos deb's for i386 and powerpc?
> > >
> > > > What do you need it for? If it's about Mach64, try
> > >
> >
Hello !
I'll run it later on different alphas, but I checked it on a
ppc-machine running AIX if this is of any interest to you:
[EMAIL PROTECTED]: /root # ./readmem.aix.x
Reading data from /dev/mem...
read #2 of 8192 bytes
...
read #1024 of 8192 bytes
done with read of /dev/mem (returned 1).
su
On Mon, Aug 26, 2002 at 04:28:38PM +1000, matthew green wrote:
> wow, this is such a bad idea.
It originated upstream.
mmm, xdm.
In fact, judging by CVS logs it has been in xdm's source for many, many
years.
bad ideas often hang around for a long time. the only surpris
Branden,
Successfull runs on an x86 2.4.18 Debian 3.0 and a ppc "homegrown" 2.4.7-10
machine.
Branden Robinson wrote:
The long story, for those interested:
http://lists.debian.org/debian-x/2002/debian-x-200208/msg00091.html
(and read the whole thread)
The short story:
I need people with ro
HP rx4610 (4x Itanium), Debian unstable, 2.4.18-itanium-smp
Works without problems
HP i2000 (Itanium), Debian unstable, 2.4.18-itanium
Machine hangs after read #40; works with "fragile"
DEC UDB (Alpha 21066), Debian unstable, 2.4.6
Works without problems
I do think that blindly reading /dev/mem
On Mon, 26 Aug 2002, Branden Robinson wrote:
> 1) whether or not this program works when you run it without arguments
.
.
read #1023 of 16384 bytes
read #1024 of 16384 bytes
done with read of /dev/mem (returned 1).
sumFile() succeeded.
Behaves the same with fragile, tested on two pci-based alpha
On Mon, Aug 26, 2002 at 04:28:38PM +1000, matthew green wrote:
> wow, this is such a bad idea.
It originated upstream.
In fact, judging by CVS logs it has been in xdm's source for many, many
years.
> why don't you use /dev/urandom if it exists, as it does on pretty
> much all modern UNIX platfor
Be warned: on at least some architectures (notably IA-64), this sort of
read has been known to cause untrapped machine checks (a.k.a., lockups
or spontaneous reboots). Arguably the kernel should trap this sort of
nonsense, so you may be in the mood to file a bug against "kernel" af
The long story, for those interested:
http://lists.debian.org/debian-x/2002/debian-x-200208/msg00091.html
(and read the whole thread)
The short story:
I need people with root on machines of your given architecture to
compile and run the attached C program. It consists of code borrowed
from xdm
49 matches
Mail list logo
