>
> PR bin/3546 asks that `ktrace(1)' not be allowed on files that do not have
> read permissions for the user attempting to execute them.
>
> The intent of this change is to prevent a user from seeing how an
> executable with '--x--x--x' perms works by ktrace'ing its execution.
>
> My questio
> jk> The intent of this change is to prevent a user from seeing how an
> jk> executable with '--x--x--x' perms works by ktrace'ing its execution.
>
> jk> My question to -hackers is: is this a useful semantic? Would it break
> jk> anything if added?
>
> nw> If we make kernel auditing based upo
> The PR proposes (and the patch given earlier implements) tighter
> security on the premise that security in the presence of KTRACE
> should be at least as tight as without KTRACE. It achieves this
> by requiring read permissions on an executable before it can be
> KTRACE'd.
As other have pointe
> > LD_LIBRARY_PATH, LD_PRELOAD and LD_DEBUG are ignored for setuid executables
> > in FreeBSD.
>
> But the point being made is that they are not ignored for executables
> which have no read access. And from there, read access can be gained,
> because at that point, you have code running in the p
> > > > LD_LIBRARY_PATH, LD_PRELOAD and LD_DEBUG are ignored for setuid
> > > > executables
> > > > in FreeBSD.
> > >
> > > But the point being made is that they are not ignored for executables
> > > which have no read access. And from there, read access can be gained,
> > > because at that poin
> > :So, I've a box that I have an ipfw ruleset on. The firewall should not be
> > :changeable during runtime, and the box runs at securelevel=3.
> > :
> > :In order to prevent DoS disk-fill attacks, I also have specified
> > :IPFW_VERBOSE_LIMIT.
FWIW, as you pointed out below, this was put in sp
> > > Having a per-rule limit means that you
> > > actually have a "IPFW_VERBOSE_LIMIT * number_of_rules_specifying_log"
> > > limit
> > > (assuming an attacker exploits multiple rules) rather than a limit of
> > > "IPFW_VERBOSE_LIMIT".
> >
> > I disagree. I have *tons* of firewall rules, and I
> > You get *better* information on per-rule limits than on a global limit.
>
> No, you simply get a finer-grained ability to select.
Which is almost always better.
> > > If I'm an admin, I'm going to think "Well lets see, I want to store a
> > > month of bad packets in it.
> >
> > If you're an
> :Instead of zeroing it, how about raising the logging limit to (current +
> :whatever the limit was)
> :
> : Brian Fundakowski Feldman _ __ ___ ___ ___ ___
> : gr...@freebsd.org _ __ ___ | _ ) __| \
>
> The way I see it either some piece of software is monit
> :That doesn't mean we shouldn't allow people to have an unsophisticated setup,
> :just because a sophisticated one is available. It would be useful to have
> :a per-firewall-rule counter, decrement it on each match if logging and
> :set, and be able to reset to something higher.
> :
> : Brian Fun
> I like the ability at secure level 3 to only reset the counters forward..
> It fits in with such things as the "append only" flag.
Then we'd have to implement per-rule counters that default to
IPFW_VERBOSE_LIMIT but that could be changed to anything. That's a very
different setup than what we c
> ipfw allows you to clear counters. It is a feature that already exists.
>
> However, it does not allow you to do it if you are sitting at secure
> level 3.
>
> Why not? I can't think of any good reason why clearing the counters
> should be disallowed when sitting at a hig
> Peter Jeremy writes:
> > > If it ever gets
> > >committed (I don't think it's particularly useful myself),
> > That's 2 against, 1 (me) for.
>
> Three against.
4 against.
Nate
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
> > How do you figure? Currently, the kernel will quit 'logging' denied
> > packets when the counter reaches a specific (compiled-in) number.
> ^
> Then what is
>
> net.inet.ip.fw.verbose_limit: 0
Well I'll be. You learn something new ev
> > (Another thing I just thought of is that this could cause DoS attacks on
> > the system if a user compromised root and then set the limit to a very
> > high number.)
>
> If you have someone going berzerk as "root" on a firewall you're definitely
> going to have a completely different set of he
> > > > One could argue that accounting numbers in a firewall shouldn't be
> > > > trusted, but I won't argue that point since the firewall is often the
> > > > most 'natural' place to stick network accounting software.
> > >
> > > If you can't trust something in the kernel, then you just can't tr
> > > I like the ability at secure level 3 to only reset the counters forward..
> > > It fits in with such things as the "append only" flag.
> >
> > Then we'd have to implement per-rule counters that default to
> > IPFW_VERBOSE_LIMIT but that could be changed to anything. That's a very
> > differ
> > Again, it's not a fix, it's a feature. Not being able to mess with
> > counters (logging or otherwise) is a feature. It may be a feature that
> > you can do without, but that decision is not to be made lightly.
>
> I'm _saying_ to create a completely separa
> > > > Again, it's not a fix, it's a feature. Not being able to mess with
> > > > counters (logging or otherwise) is a feature. It may be a feature that
> >
> > > > you can do without, but that decision is not to be made lightly.
> > >
> > > I'm _saying_ to cr
> If it will get ALL of you to give it a rest, how about:
> per-rule logging limits
> logging limit raising
> logging limit resetting
> Which would all NOT affect the statistics?
We need more input from people who use the code, to make sure they don't
depend on the current 'featu
> And then ... securelevel == 3 I think it is better NOT to permit
> 'sysctl -w', 'ipfw *' AND a logging limmit, just process the logfile
> faster to avoid DoS
The real issue we are dealing with is what happens at securelevel == 3.
What you are saying is that people shouldn't be allowed to modify
> > Implementing it is the easy part, making sure it's the right thing to do
> > is the hard part.
>
> Well, the easy part is done, except for raising limits. Look:
> ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via lo0
> ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via lo0
> ipfw: limit 2 reach
> > > > Implementing it is the easy part, making sure it's the right thing to do
> > > > is the hard part.
> > >
> > > Well, the easy part is done, except for raising limits. Look:
> > > ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via lo0
> > > ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via l
> Index: src/sys/netinet/ip_fw.c
> ===
> RCS file: /home/ncvs/src/sys/netinet/ip_fw.c,v
> retrieving revision 1.114
> diff -u -r1.114 ip_fw.c
> --- ip_fw.c 1999/06/19 18:43:28 1.114
> +++ ip_fw.c 1999/07/28 06:29:07
> @@ -106,6
> > > @@ -302,14 +303,15 @@
> > > struct ifnet *rif, struct ifnet *oif)
> > > {
> > > if (ip) {
> > > + struct tcphdr *const tcp = (struct tcphdr *)((u_int32_t *)ip+ip->ip_hl);
> > > + struct udphdr *const udp = (struct udphdr *)((u_int32_t *)ip+ip->ip_hl);
> > > + struct icmp *const icmp =
> > > These were changes that were necessary to make ipfw readable enough that
> > > I could work with it in this area. They aren't just to clean it up, or
> > > just for change's sake. They need to stay in.
> >
> > C'mon now, re-ording the lines is *certainly* not necessary to work.
>
> That's t
> > > *rant on*
> > > Brian, FreeBSD isn't your private playground for playing around, this is
> > > a group project, and you gotta follow the rules, or you don't get to
> > > play with the rest of the folks
> >
> > The rules don't say "leave the code that you work with in a bigger mess than
>
> > > > > These were changes that were necessary to make ipfw readable enough
> > > > > that
> > > > > I could work with it in this area. They aren't just to clean it up, or
> > > > > just for change's sake. They need to stay in.
> > > >
> > > > C'mon now, re-ording the lines is *certainly* not n
> > > > In particular, the changes I pointed out are not 'cleanups', but style
> > > > changes.
> > >
> > > When you make code readable, it's a cleanup.
> >
> > The code is *NO* more readable by you re-ordering lines and changes
> > whitespace.
>
> This is so very objective.
That's why it consi
> This is a clear security vs functionality issue and I need to get a
> good feel for which "cause" is ascendent here in knowing which way to
> jump on the matter. Can we now hear the closing arguments from the
> pro and con folks?
I thought we decided that the networking gurus we're going to mak
[ VMWare ]
> what's needed is customer presence.
If people could send me an email address where I could send and state my
interest in a VMWare port for FreeBSD (I would of course pay for a copy
of VMWare if it existed), I'll do it.
The stuff on the WWW page is too 'generic', and I'd rather get i
> > ---Steve Tarkalson said:
> > > this is solved by one of two methods:
> > >1-) require the caller of gethostbyaddr() to supply a pointer to
> > >a hostent struct which will be filled.
> > > or 2-) the library uses thread specific storage which is re-used in
> > >each call.
>
> : There
> : is simply no reason to assume that anything under a gnu directory is GPLd,
> : or that anything GPLd is going to be under a gnu directory (which it's not.)
>
> I'm afraid there is. It has been stated many times in the past that
> all GPL'd software resides under gnu. This is true i
> > Both struct timespec and struct timeval are major mistakes, they
> > make arithmetic on timestamps an expensive operation. Timestamps
> > should be stored as integers using an fix-point notations, for
> > instance 64bits with 32bit fractional seconds (the NTP timestamp),
> > or in the future 1
> > Matt doesn't represent the FreeBSD project, and even if he rewrites
> > the VFS subsystem so he can understand it, his rewrite would face
> > considerable resistance on its way into FreeBSD. I don't think
> > there is reason to rewrite it, but there certainly are areas
> > that need fixing.
>
> implemented at least up to 3.2-stable. How could one ensure that their
> threads in an application can be "equally" distributed to all the
> processors in FreeBSD?
You can't.
> Are there any documents on FreeBSD 3.*'s thread
> support(both kernel and user level)?
FreeBSD has no kernel 'thr
> > FreeBSD has no kernel 'thread' support, only user level.
>
> That's not strictly true. The fact is we have both kernel and user
> threads but no mapping between the two... The kernel already
> internally use some threads.
Your definition of kernel threads and mine are obviously quite
differen
> I had always wondered how select/poll worked (actually see the end of the
> mail to see the broader question), so I pulled up select() and family
> and started reading and chasing stuff around. I think that I fully
> understand (much praise to whoever wrote most of that, it was incredibly
> easy
> > Matt doesn't represent the FreeBSD project, and even if he rewrites
> > the VFS subsystem so he can understand it, his rewrite would face
> > considerable resistance on its way into FreeBSD. I don't think
> > there is reason to rewrite it, but there certainly are areas
> > that need fixing.
>
> > [...]
> > 2. value ) instead of value) for case statements
> > [...]
> >case $? in
> > - 0)
> > + 0 )
> >;;
> > - 2)
> > + 2 )
> >exit 1
> >;;
> > - 4)
> > + 4 )
> >reboot
> >echo "reboo
[ I'm nit-picking here, feel free to ignore ]
> Doug--- /usr/src/etc/rc Thu Aug 26 20:56:36 1999
> +++ rcFri Aug 27 09:52:39 1999
> @@ -8,24 +8,25 @@
> # and the console is the controlling terminal.
>
> # Note that almost all the user-configurable behavior is no longer in
> -
> > I have the feeling that "Software Licensing Program" speaks .
>
> You can read about the Sun Community Source License on their web site now.
> It is the same license that brings the JDK to FreeBSD.
*NOT* As we read it (The JDK folks), the CSL doesn't allow us to release
the JDK on FreeBSD
> There was such a thing in 386BSD and FreeBSD1.0
I remember no such thing doing a 'bogomips' to compare against Linux.
Certainly not in 386BSD.
Nate
>
> I certainly thing it was a worth-while thing.
> I'd try make the loop as similar to the Linux one so that they are
> comparable.
>
> On Th
> : I'd really like to see the sio driver code being able to support PCI
> : devices...
>
> Might be a good time have a sys/dev/sio and have pccard, cardbus, pci
> and isa attachments there. Yes, I did say cardbus, since I have seen
> cardbus PCI modems that are NOT winmodems.
But, they should
> "Matthew N. Dodd" wrote:
> > On Sun, 5 Sep 1999, Warner Losh wrote:
> > > Might be a good time have a sys/dev/sio and have pccard, cardbus, pci
> > > and isa attachments there. Yes, I did say cardbus, since I have seen
> > > cardbus PCI modems that are NOT winmodems.
> >
> > And MCA and EISA at
> : But, they should be PCI/non-Winmodem, as Kevin pointed out, so we
> : shouldn't need cardbus seperately from pci.
>
> Just the attachment...
Ahh, OK. I'm not familiar enough with the new code to know how exactly
it's organized. :)
Nate
To Unsubscribe: send mail to majord...@freebsd.org
w
> > 3. Needlessly cross-posted (watch your cc lines, loser! :).
>
> On a different topic, does anyone know of a good X mailer
> (currently I am using exmh) :
>
> 1. user friendly
> 2. filtering capability
> 3. thread topic support
XEmacs + VM works very well for me, but Emacsen have a fairly la
> Nate: it's a while since I looked at VM on XEmacs. I found its
> layout cluttered and it's key sequences awkward. How configurable
> is it, really? Do you use it as it comes out of the box?
Really configurable, and no, I don't use it in an out-of-the-box
configuration.
I remap many of the ke
> Just to toss in my 0.02 cents, I've been using exmh for a while and
> am on one hand very satisfied with it, on the other hand it's handling
> of mime and html is not good, so I'd be very interested in discussing
> this topic too.
VM doesn't do HTML/MIME very well, although I understand in late
> > > I strongly disagree. Spitting "unresolved references" is *not* a way to
> > > tell the user that he doesn't have the right libraries.
> >
> > I strongly disagree. This is much better than version bump. After all,
> > we can add suggestion to upgrade libraries to the "unresolved references"
>
> > > Yes, we shouldn't version bump every time someone has a whim, ending
> > > up with 10 version bumps/week, but neither should we avoid them
> > > altogether and cause the Linux syndrome of programs refusing to work
> > > because they have the *wrong* version of glibc2.3 (or whatever)
> >
> > For what it's worth, I agree with Marcel. Version bumps should be
> > discouraged, but not totally avoided.
>
> What is the reason to not avoid the version bump?
Because if you don't have the latest/greatest library (old machines),
newer programs that are compiled against the latest/greates
> > VM doesn't do HTML/MIME very well, although I understand in later
> > versions of XEmacs they've incorporated some packages that handle things
> > better. (I'm still using XEmacs 19.16, from the dark ages...)
>
> Does it do IMAP?
It doesn't even do POP, I use fetchmail/procmailrc to get m
> The box is just going to be running NATD and IPFW, maybe DHCLIENT.
>
> Mr. NT is been told he can try and break-in, crash what ever this box
> from the internet side.
>
> I am asking for links, pointer to make sure this is configured as
> secure/solid as possible. I will be installing 3.3-STAB
> > I know that in some other Bsd flavours you can use the sysctl functions =
> > which is part
> > of the ifnet struct. In FreeBsd I didn't find anything similiar to it.
>
> Sysctl functions aren't "part of the ifnet struct". You can define
> sysctls for your driver, if you wish, but that's the
> -
> and here's the ld line for the shared object I am loading;
>
> ld -Bshareable -o $@ $< -u _floor ../../lib/libV.a
> /usr/local/lib/mysql/libmysqlclient.a /usr/lib/libm.a
This is probably unrelated to the bug (but it might be related).
> Is it possible to change the mac address of an ethernet card using
> ifconfig?
Not in any 'standard' card, no. Some cards (in SUN workstations) allow
you to swap the EEPROM with the mac address, and I'll bet somewhere
someone has designed a card with a programmable mac address, but
normally it
> For people who have idle cpu to spare, this is a good time to start
> putting those cycles to good use with the Seti project!
Where would would find informatio on said project?
Nate
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of t
> : [ gps talk ]
> :...
>
> I've been very impressed with the newer ( last 5 months ) Garmin
> handhelds. The older ones only had 8 channel receivers. The newer
> ones have 12 channel receivers sensitive enough that the units often
> work indoors.
FWIW, the Garmin 12XL is a *ve
[
Some history: I'm not a core member (I gave that up responsibility years
ago), but I was one of the three weirdo's that started up FreeBSD back
when I had no life. My opinions are my own, and don't reflect the core
team. I don't know the exact reasons why the core team removed Matt's
commit pri
[
None of the below is assumed to be taken as reflecting any situation
that occurred in FreeBSD. This is a *common* problem that exists in
every software program, and any reflection on what happened in FreeBSD
is by coincedence in that it's a software program. My comments apply
as easi
> | I know of *NO* programmer who does not delight in completely ripping out
> | and replacing existing code with code that he has written from scratch.
> | It's great fun, and it allows the person to feel better about the
> | system, themselves, and make sure that they can debug the existing code
> > > We're adding some machines at work for (essentially) cgi
> > > processing only. It was never considered to use anything less than 2 cpu
> > > boxes, and the current round of testing is going so well that we're
> > > seriously considering 4 cpu boxes because they are not that much more
> > >
[ Trimmed CC list a bit ]
> > :* even if you are not willing to pay that price, there _are_ people
> > :who are quite willing to pay that price to get the benefits that they
> > :see (whether it's a matter of perception or not, from their
> > :perspective they may as well be real) of such a scheme
> :> > Quite true. In the embedded world we preallocate memory and shape
> :> > the programs to what is available in the system. But if we run out
> :> > of memory we usually panic and reboot - because the code is designed
> :> > to NOT run out of memory and thus running out of me
> :Most of the work we've done wouldn't allow this, especially if we were
> :using an OS like FreeBSD with a fairly long bootup time. Especially if
> :it can be avoided.
> :
> :Yes, we could (and did) do our own memory management, but it seems to me
> :that the kernel has alot more information ava
> :Returning NULL isn't an error, it's an indication that there is no more
> :memory. Don't think if it as an error, think of it as a hint.
>
> It's only a hint if it is returned due to the process resource limit
> being hit. If it is returned due to the system running out of swap,
>
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
> >
> > 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 <[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
> > 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
[ 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
> >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
> >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
> > > >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
> > > 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
> 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
> > > 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
> 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
> > 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
[ 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
> > 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
> > > > 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
> > > 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.
> >
> >
> > > 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
> Besides, have you even established that dynamically linked programs
> load too slowly? I've certainly never heard any complaints along
> those lines. Furthermore I would bet that the bulk of the dynamic
> linking time comes from opening the shared libraries and mmapping
> them, and there's not
> > Mike Smith wrote:
> > > gzipped binaries are actually a terrible idea; they actually *waste*
> > > space in most cases.
> >
> > Suprising, They saved space for a 200M disc in a 486 laptop with 3.[2,3,or4],
>
> No, that's the one case where they help. But people aren't trying to
> squeeze
> > PosixThreads are userland threads - if one thread blocks on i/o the
> > whole process is blocked. Which makes PosixThreads rather useless.
>
>That is incorrect. FreeBSD's userland pthread implementation
> does not block the whole process on I/O. POSIX does not specify
> this behavior ei
> > You normally wouldn't mix kqueue and threads; you'd use kqueue to
> > *implement* threads. :-)
> >
> > AFAIK kqueue hasn't been made threadsafe, you'll have to bug
> > [EMAIL PROTECTED] about it. Patches gladly accepted :)
>
> I may be just being stupid but I don't understand that last sente
[ CVS has screwy behavior ]
> CVS has a heuristic that does the wrong thing for this particular
> file.
[ Code and discussion deleted ]
> I hope current
> versions of CVS force the dates to be the same on an import. I
> haven't checked to see whether that's the case or not.
Suggestions like
> > > I don't know about the "bsd" or whatever way. If you're doing real
> > > parallel programming and want real performance, you'll use a test-and-set
> > > like function that uses the low-level machine instructions for same.
> >
> > That is exacly what I'm looking for! I found it to be overkil
> > We are trying to create a dynamic library of extensions to PHP 4.02.
> > This library implements a C++ class and has a C interface using the "Extern C"
> > declaration.
> > This library is linked with libstdc++.so.3 .
> >
> > If the library is called in a C program => no trouble.
> > If the l
> > At one point libgcc was shared (FreeBSD 1.*), and it caused way more
> > problems that it solved.
>
> Do you remember any details? I analyzed it pretty thoroughly (I
> thought) more than a year ago, and decided the shared library was the
> best solution.
If I remember right (and my memory i
> [shared libgcc?]
> > If I remember right (and my memory is fuzzy for stuff that far bak)
> > there were a couple of issues.
> >
> > 1) Speed. Shared libraries are slower than static libraries (PIC
> >et. al), and the stuff in libgcc tends to be performance centric.
>
> True. But if we ju
[ Culled the list way down, and moved it to -hackers ]
> We could also look into providing an "update" command or something
> which would pull either sources or binaries over from a snapshot box
> and make the process of getting up to the branch-head a lot easier.
> It's long been on my wishlist
> > I think that we can do a lot with cvsupd. I've used cvsupd to grab
> > binaries on an experimental basis and it seems to work great. I've
>
> Hmmm. Does cvsupd also move a target out of the way if it already
> exists and it's in the process of replacing it? What if the target is
> chflag'
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 articles, and noted that conne
> > 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
> 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.
> >
> > *sigh*
> >
> > Thanks to Guy Helmer for being patient with me as I fretted about thi
1 - 100 of 278 matches
Mail list logo
