hi,
Does anyone (anyone, that is, who's coded X11 applications) know how you
handle X11 callbacks to C++ object methods?
Thanks,
TDR If you mean Xt (and possibly Motif) - the answer is "very carefully."
TDR The Xt callbacks are C based, so you typically can't directly call a
TDR
[EMAIL PROTECTED] (Chuck Robey) writes:
Boy, I sure wish Java compiled and ran natively. I'd stop using C++
forever.
gcc-2.95.1 + libgcj already works, at least for simple programs. On
FreeBSD 3.x programs seem to work as long as you use statically linked
libraries (shared libraries cause
Greetings ..
When doing a pci_read_config(dev, PCI_LATENCY_TIMER, 4) I get varying values on
different hardware configurations.
On Machine A the value is 32 and my device driver (using DMA) works fine.
On Machine B the value is 64 and my device driver doesn't work fine - there
seem
s to be
On Thu, 21 Oct 1999 13:44:47 -0400, Robert Watson wrote:
I have not yet figured out how to get rid of the two warning messages at
startup, which are irritating but appear not to actually break anything.
http://www.stat.duke.edu/~sto/StarOffice51a/install.html
Ciao,
Sheldon.
To
On Tue, 26 Oct 1999, Andrey Simonenko wrote:
I made some days ago UNILOAD v.1.2, the main feature of this version is
the ability to load system from beyond 1024 cylinder mark. Here it is
Woo, that feature is _very_ useful. What about incorporating this
into FreeBSD's boot code ?
I've noticed something peculiar over the past week or so with
xntpd and I think xcdplayer (from ports). I am running xntpd
to keep my clock right. I have an always on DSL connection,
so I almost never see any output from xntpd.
However, I've noticed that the past few times I've started
playing
Hi
I have box running 3.3-STABLE which locks up several times per day.
After system hangs, ps command in DDB displays a lot of processes
in "inode" state. I suspect deadlock occurs:
process 45676 unlink("msg/..")
holds lock to "msg"
tries to acquire lock
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
I am using FreeBSD 3.3-RELEASE, and it is running on a single processor
PII 400.
At first, I thought the problem was due to the network driver, so I
swapped network
cards. But, the problem still continues to occur. At first, I used a DEC
Hello
I use natd + libalias in my test network connected to internet.
From my point of view main disadvantage of this program is, that i can't
see what' s
going on in packet alias engine, (ipfwadm -l -M, or ipfstat -s in
ipfilter) so I'm working on patches to natd and libalias which give me
that
Boris Popov wrote:
On Tue, 26 Oct 1999, Andrey Simonenko wrote:
I made some days ago UNILOAD v.1.2, the main feature of this version
is
the ability to load system from beyond 1024 cylinder mark. Here it
is
Woo, that feature is _very_ useful.
Unfortunately I haven't got hard disk
In the last episode (Oct 27), Roger Hardiman said:
I'm working with someone porting linux code to FreeBSD. Actually,
they want to port it to all BSDs.
So, rather than having
#if defined (FreeBSD) || defined (NetBSD)
|| defined (OpenBSD || defined (bsdi)
I am looking for a
#if
On Wed, 27 Oct 1999, Dan Nelson wrote:
In the last episode (Oct 27), Roger Hardiman said:
I'm working with someone porting linux code to FreeBSD. Actually,
they want to port it to all BSDs.
So, rather than having
#if defined (FreeBSD) || defined (NetBSD)
|| defined (OpenBSD ||
On Wed, 27 Oct 1999, Andrey Simonenko wrote:
What about incorporating this into FreeBSD's boot code ?
FreeBSD boot code (/usr/src/sys/boot/i386/boot0) already uses LBA
'packet' interface and can boot system from beyond 1024 cylinder mark.
Hm, I was not able to do so on the IBM's
I admittedly haven't done much homework on this topic, but I was wondering
if anyone has played with the idea of implementing ACLs on top of UFS.
One of the weakest areas in UNIX is its lack of fine-grained access
control for resources - the biggest resource being, of course, the
filesystem.
I admittedly haven't done much homework on this topic, but I was wondering
if anyone has played with the idea of implementing ACLs on top of UFS.
One of the weakest areas in UNIX is its lack of fine-grained access
control for resources - the biggest resource being, of course, the
-BEGIN PGP SIGNED MESSAGE-
Well, guys, listen :-)
I and my friends mentioned that "FreeBSD + ffs" is often slower
(THAT slower) than "Linux + ext2" for number of tasks:
rm, find, tar ... for IDE SCSI disks.
I didn't try things like "FreeBSD + ext2" or "Linux + ffs".
I attached here
One of the biggest reasons for the difference: FreeBSD, by default,
performs _synchronous_ metadata updates, and Linux performs asynchronous
metadata updates.
It's definitely a bit slower, but the payoff is in reliability. I have
seen more than one [production!] Linux machine completely
On Wed, 27 Oct 1999, Chuck Youse wrote:
One of the biggest reasons for the difference: FreeBSD, by default,
performs _synchronous_ metadata updates, and Linux performs asynchronous
metadata updates.
It's definitely a bit slower, but the payoff is in reliability. I have
seen more than
On Wed, 27 Oct 1999, Chuck Youse wrote:
One of the biggest reasons for the difference: FreeBSD, by default,
performs _synchronous_ metadata updates, and Linux performs asynchronous
metadata updates.
It's definitely a bit slower, but the payoff is in reliability. I have
seen more than
There is actually a discussion beginning on freebsd-fs about the
possibilty to starting a journaled file system project. Perhaps the speed
issues (as well as the ACL's issues) could be discussed there?
-don
On Wed, 27 Oct 1999, Ben Rosengart wrote:
On Wed, 27 Oct 1999, Chuck Youse wrote:
On Wed, 27 Oct 1999, Chuck Robey wrote:
On Wed, 27 Oct 1999, Ben Rosengart wrote:
On Wed, 27 Oct 1999, Chuck Youse wrote:
One of the biggest reasons for the difference: FreeBSD, by default,
performs _synchronous_ metadata updates, and Linux performs asynchronous
metadata
On Wed, 27 Oct 1999, Ben Rosengart wrote:
On Wed, 27 Oct 1999, Chuck Robey wrote:
On Wed, 27 Oct 1999, Ben Rosengart wrote:
On Wed, 27 Oct 1999, Chuck Youse wrote:
One of the biggest reasons for the difference: FreeBSD, by default,
performs _synchronous_ metadata updates,
On Wed, Oct 27, 1999 at 12:44:42PM -0400, Ben Rosengart wrote:
On Wed, 27 Oct 1999, Chuck Robey wrote:
On Wed, 27 Oct 1999, Ben Rosengart wrote:
On Wed, 27 Oct 1999, Chuck Youse wrote:
One of the biggest reasons for the difference: FreeBSD, by default,
performs
On Wed, 27 Oct 1999, Chuck Robey wrote:
Read the post again -- they were using soft updates.
Why is that important? Soft updates is still far better than an async
filesystem. Have you lost files in panics? I haven't.
Soft updates should get you most of the speed that async updates
On Wed, Oct 27, 1999 at 09:33:20PM +0600, Ilia Chipitsine wrote:
I did a similar test ages ago, only I was extracting a version
of the Linux kernel. The FreeBSD machine came out about 10%
faster, despite the fact it was running squid and had an older,
slower disk.
FreeBSD: 112.95 109.00 112.14
It seems Ilia Chipitsine wrote:
FreeBSD-3.3 + softupdates + "# tunefs -o time" + "flags 0xb0ffb0ff"
(kernel was compiled with "-O2")
Hmm, if you didn't do a "tunefs -n enable" you are not using softupdates
and there is your reason why FreeBSD is slower..
-Søren
To Unsubscribe:
-BEGIN PGP SIGNED MESSAGE-
On Wed, 27 Oct 1999, Ronald G. Minnich wrote:
On Wed, 27 Oct 1999, Chuck Youse wrote:
One of the biggest reasons for the difference: FreeBSD, by default,
performs _synchronous_ metadata updates, and Linux performs asynchronous
metadata updates.
-BEGIN PGP SIGNED MESSAGE-
On Wed, 27 Oct 1999, Soren Schmidt wrote:
It seems Ilia Chipitsine wrote:
FreeBSD-3.3 + softupdates + "# tunefs -o time" + "flags 0xb0ffb0ff"
(kernel was compiled with "-O2")
Hmm, if you didn't do a "tunefs -n enable" you are not using
-BEGIN PGP SIGNED MESSAGE-
On Wed, 27 Oct 1999, David Scheidt wrote:
On Wed, 27 Oct 1999, Chuck Robey wrote:
Read the post again -- they were using soft updates.
Why is that important? Soft updates is still far better than an async
filesystem. Have you lost files in
in order to save space I gzip'ped output of my tests.
ungzipping ports tarball on FreeBSD took 28 min
on Linux --- about 2.5 times faster.
This is something we already know, and it's not the sort of test that
you should ever headline as "why is FFS so much slower"?
Creation of massive
On Wed, 27 Oct 1999, Ilia Chipitsine wrote:
as far as I remember ext2 has some "counter". I used to use Linux and
it performed 'fsck' from time to time (even if fs was clearly unmounted).
that is a very good thing to have.
And it's a good thing because ... well, maybe because it's not that
:On Wed, 27 Oct 1999, Ilia Chipitsine wrote:
: as far as I remember ext2 has some "counter". I used to use Linux and
: it performed 'fsck' from time to time (even if fs was clearly unmounted).
: that is a very good thing to have.
:
:And it's a good thing because ... well, maybe because it's not
I had a nightmare problem with Linux filesystems. Yes, i'm just a newbie
recreational linux user. But i had installed mandrake 6.0, which
apparently had serious filesystem bugs that would corrupt data if the
cdrom was mounted during shutdown. I had to reinstall because of that,
and even after
On Wed, 27 Oct 1999, Ronald G. Minnich wrote:
On Wed, 27 Oct 1999, Ilia Chipitsine wrote:
as far as I remember ext2 has some "counter". I used to use Linux and
it performed 'fsck' from time to time (even if fs was clearly unmounted).
that is a very good thing to have.
And it's a good
"IC" == Ilia Chipitsine [EMAIL PROTECTED] writes:
very buggy kernel module, so things were *hosed*). The
original poster hasn't really provided enough information to
know what is going on, and what the performance problem is.
IC in order to save space I gzip'ped output of
as far as I remember ext2 has some "counter". I used to use Linux and
it performed 'fsck' from time to time (even if fs was clearly unmounted).
that is a very good thing to have.
linux performed a fsck on every 16th boot afaik. This may have been
changed but that is how often it occurred
On Thu, 28 Oct 1999, Joe Abley wrote:
On Wed, Oct 27, 1999 at 10:29:54AM -0600, Ronald G. Minnich wrote:
To put it slightly more strongly: as far as I'm concerned ext2 is not a
serious fs if you really care about handling power failures and other such
fun things.
I'm not sure I've ever
When Kirk gets his softupdates/filesystem-checkmarking code working we
are going to be a step up from anything linux could hope to accomplish
in the filesystem arena because we will then be able to reliably dump,
checkmark, AND sanity-check the filesystem on a live (and busy)
On Wed, Oct 27, 1999 at 04:22:20PM -0500, David Scheidt wrote:
On Thu, 28 Oct 1999, Joe Abley wrote:
On Wed, Oct 27, 1999 at 10:29:54AM -0600, Ronald G. Minnich wrote:
To put it slightly more strongly: as far as I'm concerned ext2 is not a
serious fs if you really care about handling
Date: Wed, 27 Oct 1999 16:55:30 -0400 (EDT)
From: Mark [EMAIL PROTECTED]
What I'm looking for Let's say there are two logins on a FreeBSD
machine. On ttyp0 is root, and user fred is logged in on ttyp1. Fred
can't su to root because he's not in wheel, and he doesn't/won't know the
root
Joe Abley wrote:
On Wed, Oct 27, 1999 at 10:29:54AM -0600, Ronald G. Minnich wrote:
To put it slightly more strongly: as far as I'm concerned ext2 is not a
serious fs if you really care about handling power failures and other such
fun things.
I'm not sure I've ever really understood
On Wed, 27 Oct 1999, Mike Smith wrote:
in order to save space I gzip'ped output of my tests.
ungzipping ports tarball on FreeBSD took 28 min
on Linux --- about 2.5 times faster.
This is something we already know, and it's not the sort of test that
you should ever headline as "why
On Wed, Oct 27, 1999 at 04:55:30PM -0400, Mark wrote:
I'm looking for a tool which I think I'll have to end up making myself.
What I'm looking for Let's say there are two logins on a FreeBSD
machine. On ttyp0 is root, and user fred is logged in on ttyp1. Fred
can't su to root
Under -current built from Oct 22 soucrces, and cdd built today, ripping
CD-AUDIO tracks just produces output files which are just a loud hiss.
I've tried this with both of my CD-ROM drives to no avail, and it used to
work for both of them under -current several months ago.
wcd0: drive speed
On 27-Oct-99 Mark wrote:
I'm looking for a tool which I think I'll have to end up making
myself.
What I'm looking for Let's say there are two logins on a FreeBSD
machine. On ttyp0 is root, and user fred is logged in on ttyp1.
Fred
can't su to root because he's not in wheel, and
Chuck Robey wrote:
On Tue, 26 Oct 1999 [EMAIL PROTECTED] wrote:
Thomas David Rivers writes:
If you mean Xt (and possibly Motif) - the answer is "very carefully."
[...]
You're approach would probably work, but there's an easier way.
See topic 28 in the Xt FAQ.
On Wed, 27 Oct 1999, Mark wrote:
I'm looking for a tool which I think I'll have to end up making myself.
What I'm looking for Let's say there are two logins on a FreeBSD
machine. On ttyp0 is root, and user fred is logged in on ttyp1. Fred
can't su to root because he's not in
On Wed, 27 Oct 1999, Wes Peters wrote:
Chuck Robey wrote:
On Tue, 26 Oct 1999 [EMAIL PROTECTED] wrote:
Thomas David Rivers writes:
If you mean Xt (and possibly Motif) - the answer is "very carefully."
[...]
You're approach would probably work, but there's an easier
On Oct 27, 2:51pm, Julian Elischer wrote:
} Subject: Re: why FFS is THAT slower than EXT2 ?
}
}
} On Wed, 27 Oct 1999, Mike Smith wrote:
}
} in order to save space I gzip'ped output of my tests.
} ungzipping ports tarball on FreeBSD took 28 min
} on Linux --- about 2.5 times faster.
}
Chuck Youse wrote:
I admittedly haven't done much homework on this topic, but I was wondering
if anyone has played with the idea of implementing ACLs on top of UFS.
One of the weakest areas in UNIX is its lack of fine-grained access
control for resources - the biggest resource being, of
This message was sent from Geocrawler.com by "Manju Radhakrishnan"
[EMAIL PROTECTED]
Be sure to reply to that address.
Hi,
I am trying to modify IP code in FreeBSD so that the packets from IP layer are not
immediately sent to the interface output but they are buffered and sent at a certain
On 27-Oct-99 Remy Nonnenmacher wrote:
In followup of the FFS thread, I would like to know if there are some
recommendations for running unattended machines. For exemple, avoiding
the 'run fsck manually' (for exemple, when co-locating a machine far
away where it is not possible to get a
On 27-Oct-99 Peter Mutsaers wrote:
The only exception might be untarring large tarballs. Linux makes more
aggressive use of the filesystem buffer; it even swaps out quite
active processes to be able to cache large amounts. The drawback is
that the system as a whole tends to become quite
On 27-Oct-99 Remy Nonnenmacher wrote:
In followup of the FFS thread, I would like to know if there are some
recommendations for running unattended machines. For exemple, avoiding
the 'run fsck manually' (for exemple, when co-locating a machine far
away where it is not possible to
On 28-Oct-99 Kevin Day wrote:
This means that it generally always gets through the fsck.. Of course if
had to delete files then they're gone, but if you value its ability to stay
without human intervention its handy.
The problem is that 'fsck -py' ignores the 'p' and will fsck every
On Thu, 28 Oct 1999, Daniel O'Connor wrote:
On 27-Oct-99 Remy Nonnenmacher wrote:
In followup of the FFS thread, I would like to know if there are some
recommendations for running unattended machines. For exemple, avoiding
the 'run fsck manually' (for exemple, when co-locating a
I have an older AlphaStation 600 5/266 running -current (cvsupped
last week) which is setup as a router between 2 100mb networks. When
the machine is pushed fairly hard (like running a netperf -tUDP_STREAM
-- -m 100 across the router, eg about 10-20k 100byte packets/sec ) the
alpha falls over
On Thu, 28 Oct 1999, Daniel O'Connor wrote:
On 27-Oct-99 Remy Nonnenmacher wrote:
In followup of the FFS thread, I would like to know if there are some
recommendations for running unattended machines. For exemple, avoiding
the 'run fsck manually' (for exemple, when co-locating a
I don't know waht really happened, but the originally quoted numbers
sound fishy to me. There may well be some other problem.
I ran two tests on my rather modest machine (P166, 64mb, UW Scsi
Drives, 3.3-Stable). I have soft updates turned on.
(correctly, I might add :-)
Unpacking the ports
On Tue, 26 Oct 1999, Andrey Simonenko wrote:
I made some days ago UNILOAD v.1.2, the main feature of this version is
the ability to load system from beyond 1024 cylinder mark. Here it is
Woo, that feature is _very_ useful. What about incorporating this
into FreeBSD's boot code ?
Please try wrapping your messages to a sane width; try 72 columns.
When doing a pci_read_config(dev, PCI_LATENCY_TIMER, 4) I get varying
values on different hardware configurations.
On Machine A the value is 32 and my device driver (using DMA) works fine.
On Machine B the value is 64 and
61 matches
Mail list logo
