> > An address that works. Without further knowledge of your laptop, it
> > is impossible for me to say. You will have to find this out by trial
> > and error. Some folks like 0xf800, others like 0x4 and
> > one uses 0xd4000, but the last one I don't recommend.
>
> 0xf800 seems
> > > It gets handled in the same way as now: I believe, CVS checks
> > > whether the checked-out version matches the top of the branch,
> > > and if it does not then it refuses to commit and requires you
> > > to make an update. So the same thing can be done for a "local branch":
> > > check that
> > > That's the plan for the next stage, provided that the first stage
> > > goes well. I'm yet to play with CVSup and see if it can be
> > > integrated there (as with system()) easily without making a lot
> > > of changes to CVS itself. Otherwise I'm aftarid it's going to
> > > be a large amount
> > > I see how you are viewing this: as a means of avoiding a full
> > > CVSup.
> > >
> > > I think the reason the cache was wanted was not to avoid the
> > > CVSup, but to allow operations *other than CVSup* to proceed
> > > more quickly?
> >
> > Having a local 'CVS' tree mirrored already does t
> > > Nate's suggestion covers the version number issue... sort of. It
> > > assumes that the patches will be approved for commit to the main
> > > repo
> >
> > This is easy to get around, b/c if the commit doesn't happen
> > successfully on the repo, then the commit fails, and as such it also
>
> > The other solution to the problem is the P4 route. Making things so
> > darn effecient that there's little need to have a local mirror. Where
> > this falls down is when the remote developer doesn't have a 24x7
> > connection to the main repository. From what I've been told ClearCase
> > all
> > The corollary to that would be to teach cvs(1) to commit changes to
> > the master repo that have been made to the local repo. Version number
> > sync would be a problem, but it'd be really cool to be able to do
> > that. With a branch mapping layer (RELENG_5_SEANC -> HEAD), people
> > could
> > > The value specified in CVSROOTCACHE is the local path to the cache
> > > repository. All the check-outs, updates, diffs etc. will be obtained
> > > from there. All the check-ins, tagging etc. will go into the master
> > > repository specified by CVSROOT. Naturally, to see these changes
> > >
> The idea is to support a "cache" repository (the one copied to a local
> machine by CVSup or CTM) transparently. So that the reads from
> directory will go from the local cache repository (and won't
> overstrain the remote server, and will be fast too), while the commits
> and other changes will
> > Wow, deja-vu!
>
> Hey! I've got a GREAT idea! I whipped up this nifty perl script and
> I can run it over the src tree to delete all the trailing whitespace!
> And even better, I can collapse tabs at the beginning of lines! What
> a great deal! That should be good for a few hundred commits!
> Heh, bet you didn't know that bento's predecessor was called "thud".
> And we had a 'ripcord' for a while too. I just dont remember exactly
> which machine it became. I think it was a temporary name for the machine
> that became hub.
Don't forget gndrsh, which was freefall's replacement (and
> PS: I still think that if your CPU pegs, you've got a loop in there
> somewhere. Most common case is a "reject" or "deny". Try changing
> all of them to "drop", instead, and see if that "fixes" it.
FWIW, deny == drop. The 'reject' rule is the one that sends out ICMP
and RST packets.
Nate
T
> > If I remember correctly he has less then 10Mbit
> > uplink and a lot of count rules for client accounting.
> > It is reason I recommend him to use userland accounting.
> > And as far as I understand a lot of count rules is
> > the reason for trouble.
>
> I removed all the count rules a week or
> > In any case, he's got something else strange going on, because
> > his load under attack, according to his numbers, never gets above
> > the load you'd expect on 10Mbit old-style ethernet, so he's got
> > something screwed up; probably, he has a loop in his rules, and
> > a packet gets trapped
> > > Try this simple ruleset:
> > >
> > > possible deny log tcp from any to any setup tcpoptions !mss
> > >
> > > ipfw add allow ip from any to any out
> > > ipfw add allow ip from any to your.c.net{x,y,z,so on...}
> > > ipfw add deny log ip from any to any
> >
> > I'd limit these to the outsid
> will freebsd+ipfw always be worse in a ~10 meg/s throughput network
> that gets attacked all the time than a purpose-built appliance like a
> netscreen ?
I think its' been said that in general, the answer is no. It should
behave as well, and is some cases better. There are cases where it will
> > So, you say that a poorly configured netscreen is no better than a poorly
> > configured freebsd+ipfw ... but what about the best possibly configured
> > netscreen vs. the best possibly configured freebsd+ipfw ?
>
> The answer to that particular question depends on what you mean
> by "configur
> Try this simple ruleset:
>
> possible deny log tcp from any to any setup tcpoptions !mss
>
> ipfw add allow ip from any to any out
> ipfw add allow ip from any to your.c.net{x,y,z,so on...}
> ipfw add deny log ip from any to any
I'd limit these to the outside interface, for performance rules.
> > You don't want to stick the 'block abnormal packets' rules at the top of
> > the list, IMO. You want those at the end, since abnormal packets are
> > *usually* the exception. Optimize for the standard case.
>
> Wow - that is _very interesting_ that you say this. We were having a
> similar d
> So you are saying that if I put in:
>
> ipfw add 1 deny tcp from any to 10.10.10.10 6667
>
> That an incoming packet for 10.10.10.10 on port 6667 will go through the
> rule set _twice_ (once for each interface) ?
No, that much is true. However, you want to optimize your firewall for
packe
> Again, thank you very much for your advice and comments - they are very
> well taken.
>
> I will clarify and say that the fbsd system I am using / talking about is
> a _dedicated_ firewall. Only port 22 is open on it.
Ah, OK. That wasn't clear from your emails.
> The problem is, I have a few
> Obviously, my goal is to mitigate as much as possible - I have accepted
> that I cannot stop all DDoS - my question is, do serious people ever
> attempt to do the mitigation/load shedding with a host-based firewall (in
> this case fbsd+ipfw) ? Or would all serious people interested in
> mitigati
[ moved to -chat, since this has no business being in -hackers anymore ]
> > > Probably true, but the better solution is to find something else (or
> > > make something else) that doesn't completely suck like TFTP does.
> >
> > Because it's used so rarely, having it suck every once in a while is
> > [ TFTP performance is poor ]
> >
> > > > > USE TFTP to get a tiny image up, and then go TCP.
> > > >
> > > >
> > > > Going to TCP soon assumes that you have a lossless medium in order to
> > > > transmit packets over. If you're using a lossy medium, TFTP (and other
> > > > UDP based protoco
> > Going to TCP soon assumes that you have a lossless medium in order to
> > transmit packets over. If you're using a lossy medium, TFTP (and other
> > UDP based protocols) can kick their butt because of TCP's assumption
> > that packet loss is a function of congestion, which is often not the
>
[ TFTP performance is poor ]
> > > USE TFTP to get a tiny image up, and then go TCP.
> >
> >
> > Going to TCP soon assumes that you have a lossless medium in order to
> > transmit packets over. If you're using a lossy medium, TFTP (and other
> > UDP based protocols) can kick their butt because
> > > No, sendfile() is only for TCP connections, TFTP is using UDP. If you
> > > want performance, use something else.
> > It's even in the manpage:
> > Sendfile() sends a regular file specified by descriptor fd out a stream
> > socket specified by descriptor s.
> >
> > Silly me. BTW, I can't us
> Would it be possible to use sendfile in tftpd?
Nope, since as someone else has pointed out, tftp uses UDP and not TCP.
The problem with TFTP is the protocol, not the implementation. It's got
a window size of 'one', so the speed is limited by the latency between
the two hosts. You could have a
> Just curious how the relationship is with Nokia's sping off of FreeBSD
> for their security platform?
The FreeBSD used on the Nokia product is different enough from the stock
FreeBSD code that a dump would be essentially useless. A dump requires
that at least have access to the symbols, and ev
> hw.busfrequency = 133326902
> hw.cpufrequency = 66700
> hw.cachelinesize = 32
> hw.l1icachesize = 32768
> hw.l1dcachesize = 32768
> hw.l2settings = -2147483648
> hw.l2cachesize = 262144
>
> Assuming that some or all of this information can be derived on x86 /
> alpha / sparc, how useful do
[ Moving this thread over to -chat as well. We'll get them all over in time ]
Raymond Wiker writes:
> Giorgos Keramidas writes:
> > Well, to be frank, I've seen a few C++ coding style documents, that suggest
> > avoiding altogether when writing in C++.
>
> I assume you mean ?
>
[ moved to -chat ]
> > Because that underlying assumption is false, and I'm making
> > fun of it.
>
> Well, that in itself is wrong. C++ code IS harder to write and write
> correctly and effeciently, as I would assume it is for any OO language.
Not so. Having done C professionally for umpteen y
> > A FreeBSD 1.X CVS tree has been found, which has it's first import as
> > 386BSD 0.1 + PK 024. There are a couple minor points that need to be
> > clarified from Caldera before it can be made public.
>
> Has there been any more progress with this?
There have been no clarifications from Cald
> >How are issues (1) and (3) above different?
> >
> >ps. I'm just trying to understand, and am *NOT* trying to start a
> >flame-war. :) :) :)
>
> If the starvation happens to hardclock() or rather tc_windup() the effect
> will be cummulative and show up in permanent jumps in the output of date
>
> >> >> Can you try to MFC rev 1.111 and see if that changes anything ?
> >> >
> >> >That produced some interesting results. I am still testing under
> >> >very heavy network interrupt load. With the change from 1.111, I
> >> >still get the microuptime messages about as often. But look how
> >>
> >> Can you try to MFC rev 1.111 and see if that changes anything ?
> >
> >That produced some interesting results. I am still testing under
> >very heavy network interrupt load. With the change from 1.111, I
> >still get the microuptime messages about as often. But look how
> >much larger the
> > A FreeBSD 1.X CVS tree has been found, which has it's first import as
> > 386BSD 0.1 + PK 024. There are a couple minor points that need to be
> > clarified from Caldera before it can be made public.
>
> Just curious, but will this be folded in the main CVS tree, or will it be
> available as
> > >> Caldera's License Agreement:
> > >>
> > >> http://www.tuhs.org/Archive/Caldera-license.pdf
> > >
> > >Thanks. However, this isn't as specific as I'd like it to be. It
> > >implies that Net1/Net2 are now 'legal', but it doesn't give explicit
> > >release of said source code.
> >
> > Well
> >> Caldera's License Agreement:
> >>
> >> http://www.tuhs.org/Archive/Caldera-license.pdf
> >
> >Thanks. However, this isn't as specific as I'd like it to be. It
> >implies that Net1/Net2 are now 'legal', but it doesn't give explicit
> >release of said source code.
>
> Well, I have never hea
> > > > Now that ancient unix has been relicensed with an old-style BSD licence,
> > > > is the FreeBSD-1.X cvs repository going to be made public?
> > >
> > > Out of curiousity, why?
> >
> > "Out of curiousity" :)
>
> Kirk was surprised by how popular the CSRG archives CDs are.
I got one of t
> > > Now that ancient unix has been relicensed with an old-style BSD licence,
> > > is the FreeBSD-1.X cvs repository going to be made public?
> >
> > Out of curiousity, why?
>
> "Out of curiousity" :)
>
> Perhaps for the same reasons I spent a half an hour getting BSD 2.11
> running on a PDP-
> Now that ancient unix has been relicensed with an old-style BSD licence,
> is the FreeBSD-1.X cvs repository going to be made public?
Out of curiousity, why?
And, where have you heard that it's been relicensed?
Nate
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-h
> > Is there a simple sysctl or a command line utility I can use to
> > determine how much free memory is available in a system?
> >
> > I've got an embedded application that has *very* limited memory, and I
> > was trying to figure out how much memory was available for the userland
> > applicati
Is there a simple sysctl or a command line utility I can use to
determine how much free memory is available in a system?
I've got an embedded application that has *very* limited memory, and I
was trying to figure out how much memory was available for the userland
applications.
'top' has somethin
> : Out of curiosity, where do MTUs < ~512 occur?
>
> Old slip links that used it to reduce latency. I suspect that there
> aren't too many of them left in the world.
You'd be suprised. I measure SLIP's effeciency (in throughput) to be
about 5-15% more effecient than PPP in older versions of F
> Remember also that Matt recently shot Reno for performance
> reasons
Actually, it was turned back on less than 72 hours later, when he
found/fixed a bug in NewReno. It was only off for a little bit, and
only in -stable.
, when compared to Linux, when he should probably have
> simply cranked i
> >> > I saw an example of switching in real mode in linux' sources (it looks
> >> > pretty clear) and thouhgt it is possible to do the same under FreeBSD.
> >> > The problem is I'm absolutely lost in FreeBSD's physical memory management
> >> > implementation (page tables and directory and so on).
> > I saw an example of switching in real mode in linux' sources (it looks
> > pretty clear) and thouhgt it is possible to do the same under FreeBSD.
> > The problem is I'm absolutely lost in FreeBSD's physical memory management
> > implementation (page tables and directory and so on).
>
> That c
> > Unfortunately, I'm unable to run tcpdump on the client, since it's
> > running NT and we're not allowed to install any 3rd party apps on it
> > (such as the WinDump package).
>
> NT??? You wouldn't happen to be seeing performance problems with
> Samba, I hope?
We're not using Samba ove
> :Note, my experiences (and John Capos) are showing degraded performance
> :when *NOT* on a LAN segment. In other words, when packet loss enters
> :the mix, performance tends to fall off rather quickly.
> :
> :This is with or without newreno (which should theoretically help with
> :packet loss).
> I believe I have found the problem. The transmit side has a
> maximum burst count imposed by newreno. As far as I can tell, if
> this maxburst is hit (it defaults to 4 packets), the transmitter
> just stops - presumably until it receives an ack.
Note, my experiences (and John
> :> FWIW, I'm seeing this as well. However, this appears to be a new
> :> occurance, as we were using a FreeBSD 3.X system for our reference test
> :> platform.
> :
> :Someone recently submitted a PR about TCP based NFS being significantly
> :slower under 4.X. I wonder if it could be related?
>
> >> Of course, if you only know GNUtar Star's standard option handling
> >> _may_ look strange. But then why did FreBSD switch to GNUtar instead
> >> of keeping a real tar?
>
> >Because there didn't exist a real tar at the time that FreeBSD was
> >created.
>
> Well this is from BSD-4.3:
[ SNIP
> Of course, if you only know GNUtar Star's standard option handling
> _may_ look strange. But then why did FreBSD switch to GNUtar instead
> of keeping a real tar?
Because there didn't exist a real tar at the time that FreeBSD was
created.
Nate
To Unsubscribe: send mail to [EMAIL PROTECTED]
w
> I started noticing some TCP weirdness when I moved my bandwidth
> stats site from my office to my colo facility last week. The colo
> is five miles away by road and 1200 miles away by network. Netscape
> would stop for seconds at a time while loading the graph images but
> there was no consist
> As a follow-up, I've just checked the newreno setting on the boxes I
> experienced the problems with - newreno is on.
> I'll try turning it off and see if I experience any problems. BTW, what does
> it do exactly?
It's supposed to make performance of resends/ACKs better in the case of
packet lo
> I had a similar problem, especially with different FreeBSD 4.x boxes (4.1.1,
> 4.2, 4.3, 4.4-stable after dirpref merge) and with Windows NT systems, but
> the crap performance was only1 limited to FTP. SSH, NFS and CVS operations
> were all fine.
We're not using any of the other listed service
> > If you want me to shutup and go into a corner, it might make you feel
> > better, but it certainly won't solve the real problem.
>
> I made it clear that my problem was not with the complaint itself.
No, you didn't.
> My problem with it was with the lack of technical backing or any
> real w
> > I know my lack of information isn't helping much, and that I've not done
> > much to help debug the problem. However, all my attempts to track down
> > what is causing this from a high-level (w/out digging into the code
> > itself and analyzing tcpdump output) have come up empty.
>
> It's no
> > FWIW, I'm seeing this as well. However, this appears to be a new
> > occurance, as we were using a FreeBSD 3.X system for our reference test
> > platform. I recently updated it to FreeBSD 4.4-RELEASE, and I'm getting
> > nothing but complaints about broken connections, poor performance, and
> >Note, some of the performance issues were made better by disabling the
> >TCP newreno implementation, but it's still poor and very inconsistent
> >for hosts not on the local network, while the Linux box next to it gets
> >much more consistent results.
>
> For what it's worth I have disabled ne
> I've just been talking with a friend of mine from the Samba team.
> He's about to change jobs, and a lot of his work in future will
> involve FreeBSD. He's just been doing some performance testing, and
> while the numbers are pretty even (since he discovered soft updates
> :-), he's noticing so
> >After Kris's recent report of 'massive speedups' using dirpref, I've
> >been toying with the idea of backing up my box, and then restoring them.
> >
> >However, backup/restore are so much faster than doing a tar/untar.
> >
> >If I do a backup of my FS, wipe the disk, will the 'restore' cause th
After Kris's recent report of 'massive speedups' using dirpref, I've
been toying with the idea of backing up my box, and then restoring them.
However, backup/restore are so much faster than doing a tar/untar.
If I do a backup of my FS, wipe the disk, will the 'restore' cause the
same (ineffecien
> > > Any chance of getting CVSup to transfer from a remote repository
> > > to a local vendor branch, instead of from a remote repository to
> > > a local repository?
> >
> > The problem is that you aren't just transferring bits from the HEAD, but
> > from multiple active branches. As John alre
> > CVS claims to support multiple vendor branches, but in practice it
> > doesn't work in any useful sense. There's at least one place in the
> > CVS sources where "the" vendor branch is hard-coded as 1.1.1. You
> > really don't want to use multiple vendor branches -- trust me. :-)
> > Use two
> > > Bill Jolitz approved a 0.5 "interim release" of 386BSD
> >
> > And then Lynn revoked this, and posted a public message to the world
> > stating what obnoxious fiends we were.
>
> Actually, Lynne didn't have the right to do this; the trademark
> was Bill's, so the revocation wasn't valid un
> > You're replying to Terry for christs sake! What did you expect if not
> > revisionist $anything ?
> >
> > Which reminds me, Adrian still oves us his story about ref :-)
>
> Poul, you're going off again, without regard for facts.
>
> Remember the last time FreeBSD history came up, I proved
> > > TRW supported a lot of the early
> > > 386BSD/FreeBSD effort, back before Walnut Creek CDROM threw
> > > in and had us change the version number from 0.1 to 1.0 to
> > > make it a bit easier to sell.
> >
> > *Huh* That's revisionist history if I've ever heard it. We
> > did a 1.0 release
> > What is the file system that uses VT_TFS in vnode.h? Is it still available
> > on FreeBSD? Thanks.
>
> Julian added it for TRW Financial Services; the first public
> reference machine for 386BSD (which later became FreeBSD and
> NetBSD) was ref.tfs.com.
So far so good. ref died an ugly hor
> >> > - I would like to cap the size of the buffer cache at 200MB,
> >> > giving us another 70MB or so of KVM which is equivalent to
> >> > another 30,000 or so nmbclusters.
> >>
> >>That also seems like overkill for the vast majority of systems.
> >
> >But probably not
> - I would like to cap the size of the buffer cache at 200MB,
> giving us another 70MB or so of KVM which is equivalent to
> another 30,000 or so nmbclusters.
I know of many scientific applications that were written with low-memory
machines in mind, which use use lots of di
> Which just brings me to another point, why not just turn ssh on by default
> and turn telnetd off by default, given the latest exploit.
As Bruce already mentioned, this is the new default in 4.4.
Nate
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the b
> > Building a new development box from a set of 2.2.8 CDs would
> > certainly be a simple and guaranteed method if that's an option
> > for you.
>
> Unfortunately it's not guaranteed...a lot of new hardware has been
> released since December 1998 (the date of 2.2.8-RELEASE). :-p
Why is that im
> > > I think you've missed the fact that the '486 solution requires an
> > > add-on board (priced at $80.) and the faster cpu solution doesnt. That
> > > adds a lot of margin to get a faster MB, more than enough to
> > > compensate for the board.
> >
> > Not necessarily. The upgraded mothe
> > > Your premise that "embedded appliances" are somehow doomed to use
> pitifully
> >
> > > outdated processors is simply wrong.
> >
> > Who said anything about pitifully outdated processors. I can buy a heck
> > of alot of CPU horsepower w/out buying the latest/greatest CPU.
> >
> >
> > > > Really? Have you even looked at the net4501 board which was mentioned?
>
> > > It's
> > > > a single-board computer constructed for some specific communication
> > > > applications, with no VGA or keyboard support, or spinning fans, and
> is
> > > > pretty inexpensive and in a
> > With the current license, this won't be installed as part of the base
> > kernel. (GPL and/or LGPL)
>
> I understand it'll continue to be a port. Am I hearing that it is
> unacceptable even as a temporary solution because of the license ?
>
> > It's been answered time and time again over th
[ It would have been helpful to have a one-line description of what NGPT
is at the top of this, rather than requiring the folks to go to a URL. ]
> - The main point of this port is to have a reasonable native freebsd
> pthread implementation till the scheduler activations stuff is ready.
With
> > http://www.microsoft.com/windows2000/interix/interixinc.asp
> > Plenty of GNU stuff there, though it doesn't say so explicitly.
> > Of course, they say it's all meant only for "legacy Unix" stuff.
>
> Can you substantiate your claim there is "plenty of GNU stuff" in
> Interix, or are you just
> I've had several marketing types approach me recently for details as
> to whether or not Microsoft was using the BSD TCP/IP stack and/or user
> utilities, and though it's always been "common knowledge" in the
> community that they were, when I set about to "prove" it I found it to
> be less easy
> > > Is there any specific reason why one needs to be able to
> > > write a lock to the CVS repo when running 'make update'
> > > to get a freshly checked out source?
> >
> > Yeah: you aren't running your CVS server in "pserver"
> > mode, and so are trying to do a lock, either in your
> > local
> You cant strong-arm companies into making their intellectual properly
> rights publicly available. its a losing argument.
Strange, in that it worked for a number of video-card vendors when
XFree86 either dropped support and/or never supported the card in
question.
Nate
To Unsubscribe: send
> > > I can handle it if there is a case where both fail, but is
> there a
> > > case where both can SUCCEED ??
> >
> > What do you mean 'both succeed'?
>
> My understanding is that, on non-broken filesystems, calls to
> mkdir(2) either succeed by creating a new directory, or fail and r
> > > >Are there filesystem type cases where this might not be the case
> > > >(NFS being my main concern )
> > >
> > > No.
> >
> > Yes. NFS doesn't guarantee atomicity, because it can't. If the
> mkdir
> > call returns, you have no guarantee that the remote directory has
> been
> > creat
> >is mkdir(3) guaranteed to be atomic?
>
> Yes.
>
> >Are there filesystem type cases where this might not be the case
> >(NFS being my main concern )
>
> No.
Yes. NFS doesn't guarantee atomicity, because it can't. If the mkdir
call returns, you have no guarantee that the remote d
> >Even in this case, there's no way to prove your code is not going to
> >crash.
>
> Sure. But you can at least prove that all crashes are the result of bugs,
> not merely design "features".
'Proving' something is correct is left as an excercise for the folks who
have way too much time on thei
[ Memory overcommit ]
> One important way to gain confidence that you're little box won't
> silently crash at the worst possible time for the customer is to
> be able to *prove* to yourself that it can't happen, given certain
> assumptions. Those assumptions usually include things like "the
> har
> > Disagree. If you want it to be portable, don't use a non-standard
> > extension to a tool, such as jikes dependency features.
> >
> > We used jikes for our day-day development, but move back to using
> > 'javac' for our Q/A and final builds. That way we can complain to Sun
> > when things d
> Jason Brazile <[EMAIL PROTECTED]> writes:
> > I want to construct a portable Makefile to build a java application.
>
> Don't bother.
>
> a) use jikes instead of javac, it's much faster and gives better
> diagnostics.
Agreed.
> b) to rebuild, just list all the source (.java) files on
> >
> > I want to construct a portable Makefile to build a java application.
> >
> I've played with Java and Make in the past, but I found that spawning a new
> instance of the Java compiler is more expensive than compiling a pretty big
> bunch of files. gcc starts up a lot quicker than a JVM.
Jason Brazile writes:
> > : I want to construct a portable Makefile to build a java application.
> >
> > That's not possible. Java specifies a half assed make system as part
> > of the language, so it is nearly impossible to use another make system
> > on top of it unless you are willing to li
> > Kernel threads out of the box?
>
> The Mach kernel makes use of a thread primitive and a task primitive;
> however, their BSD OS personality is largely single-threaded with
> something approximately equivilent to our Giant -- they refer to this as a
> "Funnel", through which access to the BSD
> > > PS. Before this starts a flame war, let me say that I really believe
> > > that MacOS X is a very good thing for everyone involved, although the
> > > choice of Mach for the microkernel seems a little arbitrary if not
> > > misguided.
> >
> > It's hardly arbitrary, though the jury's still o
> I'm going to take this off of hackers and to private email. My reply
> will be via private email.
Actually, I was enjoying the discussion, since I was learning something
in the process of hearing you debug this remotely.
It sure beats the K&R vs. ANSI discussion. :)
Nate
To Uns
> > > : 3Com 3c503ISA
> > >
> > > I think so. The ed driver supports this
> >
> > I'm pretty sure the ed driver doesn't support the 503. I think we
> > dropped support for the 503 a *REALLY* long time ago (2.1 days...)
>
> You are probably confusing it with the 501 or 505. The 503
> : 3Com 3c503ISA
>
> I think so. The ed driver supports this
I'm pretty sure the ed driver doesn't support the 503. I think we
dropped support for the 503 a *REALLY* long time ago (2.1 days...)
> : DEC EtherworksISA
> : DEC DE205 ISA
>
> don't know about these. ln
> > > I had blocked incoming TCP connections coming into my network using
> > > IPFW, and I noticed that my brother was able to establish a Napster
> > > connection, even though I had blocked it earlier.
> >
> > *sigh*
> >
> > Thanks to Guy Helmer for being patient with me as I fretted about thi
> I had blocked incoming TCP connections coming into my network using
> IPFW, and I noticed that my brother was able to establish a Napster
> connection, even though I had blocked it earlier.
*sigh*
Thanks to Guy Helmer for being patient with me as I fretted about this.
I just found out that Na
> > I had blocked incoming TCP connections coming into my network using
> > IPFW, and I noticed that my brother was able to establish a Napster
> > connection, even though I had blocked it earlier.
> >
> > I thought, no worries, I'll just block it at the port level.
> >
> > I read a couple of ar
1 - 100 of 278 matches
Mail list logo
