"Daniel C. Sobral" <[EMAIL PROTECTED]> wrote:
> Bjorn Danielsson wrote:
> >
> > I have made a small patch (about 10 lines of code) to "cron" that lets
> > people choose between localtime and gmtime for their crontab entries.
> > The choice is made depending on the setting of an environment variab
Thus spake Nate Williams ([EMAIL PROTECTED]):
> Or even more paranoid and slightly shorter. ;)
> find /local2/CVSfoo -name Root -print | fgrep CVS |
> perl -pi -e 's#/local#/local2/#g;'
Hehe, yes ;-)
But, as bp mentioned already in IRC:
find /path/to/checked/out/files/and/not/the/reposi
Anyone had a look at this?
http://www.project-udi.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Yes, I've looked at it. It's a very bad idea. I know some of the people
involved, and I spent a substantial portion of the early 90's running
aroudn doing the DDI at Sun with the notion it would bring a grand
interface for all Unices etc... I've seen many, many, efforts in this
area.
I belie
> Yes, I've looked at it. It's a very bad idea. I know some of the people
> involved, and I spent a substantial portion of the early 90's running
> aroudn doing the DDI at Sun with the notion it would bring a grand
> interface for all Unices etc... I've seen many, many, efforts in this
> area.
Mike Smith has been interested in getting FreeBSD involved in this. My
attitude has been "Over my dead body" (you have to watch out saying
things like that- someone might respond with, "Uh, okay")
On Mon, 10 Jan 2000, Peter da Silva wrote:
> > Yes, I've looked at it. It's a very bad ide
The Netgear FS105 five-port 100BaseTX switch is $84.95 at buy.com
(http://www.buy.com/comp/product.asp?SKU=10221960), though they are
back-ordered.
Matt
Alex Zepeda wrote:
>
> On Fri, 31 Dec 1999, Wes Peters wrote:
>
> > I have a good reason to revive this thread. I thought anyone who followe
Matthew Jacob wrote:
>
> Mike Smith has been interested in getting FreeBSD involved in this. My
> attitude has been "Over my dead body" (you have to watch out saying
> things like that- someone might respond with, "Uh, okay")
Uh, okay. Anything to help Mike out. ;^)
--
"W
> "Kazutaka" == Kazutaka YOKOTA <[EMAIL PROTECTED]> writes:
Kazutaka> In what environment do you have the problem?
It's coming from the keyboard drivers itself. (I.e. I see the behaviour
when logged in on ttyv*.)
Kazutaka> If you
Kazutaka> have the problem in the X session, it
In message <[EMAIL PROTECTED]> Alexander Langer writes:
: Thus spake Nate Williams ([EMAIL PROTECTED]):
: > Or even more paranoid and slightly shorter. ;)
: > find /local2/CVSfoo -name Root -print | fgrep CVS |
: > perl -pi -e 's#/local#/local2/#g;'
Yes, but older Repository files must also
>
> Anyone had a look at this?
>
> http://www.project-udi.org/
Yes; I've been talking with various of the UDI folks off and on for
several years now. It's an interesting project, and may offer us a
canned solution for our next major driver architecture upheaval.
At the moment, however, the
As I hope I conveyed in my initial reply to Peter; I think the UDI
architecture is interesting, and may have something for us to learn from
next time we feel the need to restructure our driver architecture. UDI's
real strengths are likely to show up as we try to improve our
multiprocessor perfor
On Mon, 10 Jan 2000, Matthew Reimer wrote:
> The Netgear FS105 five-port 100BaseTX switch is $84.95 at buy.com
> (http://www.buy.com/comp/product.asp?SKU=10221960), though they are
> back-ordered.
Sure, but these were in stock. :^)
- alex
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "
On Mon, 10 Jan 2000, Matthew Reimer wrote:
> The Netgear FS105 five-port 100BaseTX switch is $84.95 at buy.com
> (http://www.buy.com/comp/product.asp?SKU=10221960), though they are
> back-ordered.
And I hate to reply twice, but the switch I bought (EZXS55W) is listed at
$76.95. Hmm. :)
- alex
Christopher Sedore wrote:
>On Thu, 6 Jan 2000, Arjan de Vet wrote:
>
>> Jordan K. Hubbard wrote:
>>
>> >This is very interesting data and I was just wondering about the
>> >actual state of functionality in our AIO code just the other day,
>> >oddly enough. Does anyone have a PR# for the mention
Wes Peters wrote:
>
> Matthew Jacob wrote:
> >
> > Mike Smith has been interested in getting FreeBSD involved in this. My
> > attitude has been "Over my dead body" (you have to watch out saying
> > things like that- someone might respond with, "Uh, okay")
>
> Uh, okay. Anything to help
On Mon, Jan 10, 2000 at 10:48:29PM +0100, Arjan de Vet wrote:
> Christopher Sedore wrote:
>
> >On Thu, 6 Jan 2000, Arjan de Vet wrote:
> >
> >> Jordan K. Hubbard wrote:
> >>
> >> >This is very interesting data and I was just wondering about the
> >> >actual state of functionality in our AIO code
> convince us that we should abandon our _very_ thin driver architecture
> for one that's at least an order of magnitude more complex.
Thin is not necessarily bad as it leaves a lot of room to maneuver.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the
On Mon, 10 Jan 2000, Alex wrote:
> Wes Peters wrote:
> >
> > Matthew Jacob wrote:
> > >
> > > Mike Smith has been interested in getting FreeBSD involved in this. My
> > > attitude has been "Over my dead body" (you have to watch out saying
> > > things like that- someone might respond with, "
Recently I was tasked to find a way to scale up our MYSQL server, running
MYSQL3.22.15 on FreeBSD3.3. I've been testing a hardware RAID solution,
and found that with 6 disks in a RAID5 configuration, the system was only
perhaps 30% faster than when running on a single disk. [The 6 disks in the
R
:Recently I was tasked to find a way to scale up our MYSQL server, running
:MYSQL3.22.15 on FreeBSD3.3. I've been testing a hardware RAID solution,
:and found that with 6 disks in a RAID5 configuration, the system was only
:perhaps 30% faster than when running on a single disk. [The 6 disks in t
On Mon, Jan 10, 2000 at 03:20:38PM -0800, Scott Hess wrote:
> I've implemented a rough fix, which is to rfork() processes which I label
> "iothreads" to handle the disk I/O. The parent process running pthreads
> has a socketpair() to each of the iothreads. The iothreads wait for
> requests on th
In article <1a6101bf5bc1$4e364b20$[EMAIL PROTECTED]>,
Scott Hess <[EMAIL PROTECTED]> wrote:
>
> I've implemented a rough fix, which is to rfork() processes which I label
> "iothreads" to handle the disk I/O. The parent process running pthreads
> has a socketpair() to each of the iothreads. The
On Mon, 10 Jan 2000, Alex wrote:
> Wes Peters wrote:
> >
> > Matthew Jacob wrote:
> > >
> > > Mike Smith has been interested in getting FreeBSD involved in this. My
> > > attitude has been "Over my dead body" (you have to watch out saying
> > > things like that- someone might respond with,
> Recently I was tasked to find a way to scale up our MYSQL server, running
> MYSQL3.22.15 on FreeBSD3.3. I've been testing a hardware RAID solution,
> and found that with 6 disks in a RAID5 configuration, the system was only
> perhaps 30% faster than when running on a single disk. [The 6 disks
<[EMAIL PROTECTED]> wrote:
> > 2) Does anyone have suggestions for a solution that will be cleaner and
> > won't take man-months to implement? [Which is the redeeming quality of
> > what I've got - it took me two days to zero in on a very workable
> > solution.]
>
> Have you tried the linuxthread
:find
:> linuxthreads to meet your needs at the moment.
:
:That's being tested in parallel. The main issue with LinuxThreads is that
:we'd go from running ~25 processes on this server to running ~800.
Yes, but they are rfork(RF_MEM)'d processes - they share a lot of
context between them
* Matthew Dillon <[EMAIL PROTECTED]> [000110 16:04] wrote:
> :Recently I was tasked to find a way to scale up our MYSQL server, running
> :MYSQL3.22.15 on FreeBSD3.3. I've been testing a hardware RAID solution,
> :and found that with 6 disks in a RAID5 configuration, the system was only
> :perhap
On Mon, 10 Jan 2000, Scott Hess wrote:
> 4) Is there anyone willing to commit to testing my modified pthreads
> library against MYSQL? [I'll be stress testing it quite heavily, of
> course. It would probably also be testable against Squid with async I/O
> and multithreaded Apache 2.0.]
I'm wil
> "Scott" == Scott Hess <[EMAIL PROTECTED]> writes:
Scott> Recently I was tasked to find a way to scale up our MYSQL server, running
Scott> MYSQL3.22.15 on FreeBSD3.3. I've been testing a hardware RAID solution,
Scott> and found that with 6 disks in a RAID5 configuration, the system was only
Patryk Zadarnowski <[EMAIL PROTECTED]> wrote:
> I'm no expert on pthreads, but, if you decide to proceed with
> implementing a mixed user-land/rfork pthread implementation, may I
> suggest that you implement is through POSIX pthread_attr_setscope()
> interfaces instead of some local extension. pth
"f.johan.beisser" wrote:
>
> On Mon, 10 Jan 2000, Alex wrote:
>
> > Wes Peters wrote:
> > >
> > > Matthew Jacob wrote:
> > > >
> > > > Mike Smith has been interested in getting FreeBSD involved in this. My
> > > > attitude has been "Over my dead body" (you have to watch out saying
> > > > th
On Mon, 10 Jan 2000 [EMAIL PROTECTED] wrote:
[...]
> > 1) Does this seem like a reasonable approach? [It _works_, and well. But
> > it tastes strongly of hack.]
>
> I'm not very fond of this approach to the problem, though it can work, as
> you note. Asynchronous I/O is in my opinion a much
Hi all,
I was tinkering with mergemaster tonight adding in something that seems useful
to me. I track -stable and have found mergemaster very valuable--however,
sometimes choosing 'd' over and over again for things I don't want touched
(like root's .profile or .cshrc or /etc/networks, etc.) can
On Mon, 10 Jan 2000, Alfred Perlstein wrote:
> > :I've implemented a rough fix, which is to rfork() processes which I label
[snip]
> >
> > The linuxthreads port is at least four times faster and, since it uses
> > rfork(), will be I/O optimal. However, since only FreeBSD-4.x implements
35 matches
Mail list logo